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Nested  Transactions, 
Conflict-Based  Locking, 
and  Dynamic  Atomicity5 


1.  Introduction 

A  major  part  of  database  research  over  several  years  has  been  the  design  and  analysis  of  algorithms  to 
maintain  consistent  data  in  the  face  of  interleaved  accesses,  aborts  of  operations,  replication  of 
information  and  failures  of  system  components.  The  most  popular  and  simple  protocol  is  two  phase 
locking  with  separate  read  and  write  locks;  other  methods  include  arbitrary  conflict-based  locking, 
timestamp-based  techniques,  and  locking  that  uses  special  structure  of  the  data  (e.g.  a  hierarchical 
arrangement)  ([T],[We]  and  many  others).  A  powerful  theory  has  been  developed  to  prove  the  correctness 
of  these  algorithms,  based  on  the  idea  that  a  protocol  is  correct  if  it  ensures  that  all  executions  are 
equivalent  to  serial  executions  [EGLT],[P),[BG].  This  theory  proves  serializability  by  showing  that  a 
precedence  graph  contains  no  cycles. 

Recently,  some  ideas  in  database  system  design  and  more  general  distributed  system  design  have  led 
several  research  groups  to  study  the  possibility  of  giving  more  structure  to  the  transactions  that  are  the 
basic  unit  of  atomicity.  When  a  transaction  can  contain  concurrent  operations  that  are  to  be  performed 
atomically,  or  operations  that  can  be  aborted  independently,  we  say  that  the  operations  form 
tubtransactione  of  the  original  transaction.  Thus  we  consider  a  system  where  transactions  can  be  netted. 
This  idea  was  first  suggested  by  Davies  under  the  name  sphere*  of  control  [DJ.  A  primitive  example  of 
this  concept  is  implemented  in  System  R,  where  a  transaction  can  be  restarted  at  the  last  savepoint.  In 
general  distributed  systems  like  Argus  [LiS,LHJLSW]  or  Clouds  [A],  the  basic  services  are  often  provided 
by  Remote  Procedure  Calls  which,  at  their  best  ("At  Most  Once*  semantics),  are  atomic.  Since  providing 
a  service  will  often  require  using  other  services,  the  transactions  that  implement  services  ought  to  be 
nested. 

The  implementation  of  a  nested  transaction  system  requires  extending  the  algorithms  that  have 
previously  been  considered  for  concurrency  control,  recovery  and  replication.  The  work  of  Reed  [R] 
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extended  multi-version  timestamp  concurrency  control  to  provide  nested  transaction  data  management  . 
Moss  [Mo]  extended  two  phase  locking  with  separate  read  and  write  locks  to  handle  nesting,  and  this 
algorithm  is  the  basis  of  data  management  in  the  Argus  system  implemented  at  MIT. 

In  this  paper  we  develop  a  powerful  method  for  showing  the  correctness  of  concurrency  control 
algorithms  for  nested  transaction  systems.  We  introduce  a  simple  local  property,  which  we  call  dynamic 
atomicity,  and  we  show  that  a  system  is  serially  correct  for  non-orphan  transactions  (as  defined  for  nested 
systems  in  [LM])  provided  each  object  in  the  system  is  dynamic  atomic.  The  corresponding  definitions 
and  results  for  systems  without  nesting  were  first  given  by  Weihl  [We].  Our  discussion  covers  both 
concurrency  control  and  recovery  from  aborts.  However,  we  do  not  consider  all  the  failure  cases  that  the 
real  system  must  deal  with,  as  our  model  does  not  yet  include  crashes  that  compromise  the  system  state. 

To  illustrate  the  power  of  these  ideas,  we  introduce  here  a  new  algorithm  for  concurrency  control  in 
nested  transaction  systems.  Our  algorithm  allows  more  concurrency  than  Moss’  algorithm  by  using 
semantic  information  about  conflicts  between  operations  of  abstract  data  objects.  As  an  example  of  such 
semantic  information,  consider  a  data  object  that  represents  a  bank  account,  with  operations 
DEPOSIT(AMT),  WITHDRAW(AMT),  and  BALANCE.  The  DEPOSIT  operations  modify  the  state  of  the 
object,  so  ordinary  Read/Write  locking  would  not  allow  two  DEPOSIT  operations  to  run  concurrently. 
However,  there  is  really  no  harm  in  allowing  this  concurrency  if  the  operations  are  implemented 
appropriately  (for  example,  by  recording  an  "intention  to  deposit*  in  the  object’s  history)  since  the  final 
balance  is  independent  of  the  order  in  which  the  deposits  are  performed.  This  property  is  usually 
described  by  saying  that  the  two  DEPOSIT  actions  "commute",  and  that  therefore  their  locks  need  not 
"conflict".  The  algorithm  we  give  combines  the  techniques  of  Moss’  algorithm  with  the  arbitrary 
conflict-based  (but  un-nested)  locking  algorithm  of  Weihl  [We]. 

We  prove  that  any  object  implemented  using  our  "Conflict-Based  Locking"  algorithm  is  dynamic 
atomic,  and  thus  that  a  system  in  which  the  objects  are  implemented  this  way  is  serially  correct.  We  also 
show  that  objects  implemented  using  Moss’  algorithm  for  Read/Write  Locking  are  dynamic  atomic.  We 
believe  that  other  concurrency  control  techniques  can  also  be  proved  to  yield  dynamic  atomic  objects.  The 
results  in  this  paper  show  that  a  nested  transaction  system  is  serially  correct  if  each  object  is  implemented 
using  a  concurrency  control  mechanism  that  guarantees  dynamic  atomicity. 

This  paper  is  part  of  a  major  research  effort  to  offer  clean,  readable  descriptions  of  algorithms  for 
managing  data  in  a  nested  transaction  system,  together  with  rigorous  proofs  of  the  correctness  of  these 
algorithms.  Other  parts  of  the  project  include  studying  replicated  data  management  algorithms  [GL], 
orphan  elimination  algorithms  (HLMWj,  and  concurrency  control  using  timestamps  [As].  All  this  work  is 
based  on  a  simple  model  of  concurrent  systems  using  I/O  automata  and  an  operational  style  of  reasoning 
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about  their  schedules.  The  first  fruits  of  this  program  are  detailed  in  [LM],  which  proves  the  correctness 
of  exclusive  locking,  and  provides  a  basic  framework  for  presenting  the  ideas  of  this  paper. 

In  this  paper,  we  first  review  the  I/O  automaton  model  of  computation.  This  is  similar  to  models  like 
Communicating  Sequential  Processes  [Ho],  in  that  automata  interact  by  synchronizing  on  shared 
operations.  The  main  difference  from  other  models  is  that  we  distinguish  the  input  and  output  operations 
of  each  automaton.  Any  operation  shared  between  components  of  a  system  can  be  an  output  of  at  most 
one  component,  and  that  component  is  in  control  of  the  operation,  because  no  automaton  is  allowed  to 
refuse  to  execute  an  input.  Though  automata  have  states  as  well  as  operations,  we  concentrate  our 
analysis  on  the  sequence  of  operations  performed  (the  schedule  of  the  system)  -  this  operational  mode  of 
reasoning  is  quite  different  from  assertional  invariant  methods  used  elsewhere  in  reasoning  about 
distributed  systems,  but  we  find  it  very  powerful  and  yet  simple  for  the  set  of  problems  we  consider. 

Next,  we  show  how  to  use  I/O  automata  to  model  the  parts  of  a  nested  transaction  system.  Each 
transaction  process  is  represented  by  an  automaton,  as  is  each  data  object.  The  actions  of  calling  a 
subtransaction,  invoking  an  access  to  an  object,  and  returning  a  result  are  each  split  into  two  operations, 
one  requesting  the  action  and  one  delivering  the  request  to  the  recipient.  The  request  operation  is  an 
output  of  the  caller  and  an  input  to  the  controller  (which  acts  as  a  communication  system)  while  the 
delivery  operation  is  an  output  of  the  controller  and  an  input  of  the  recipient.  Thus,  each  transaction 
(and  each  object)  shares  operations  only  with  the  controller.  A  serial  system  is  the  result  of  composing 
transaction  and  object  automata  with  a  very  restricted  controller  called  the  serial  scheduler,  which  runs 
the  subtransactions  of  any  transaction  sequentially  (with  no  concurrency  between  siblings)  and  only 
aborts  transactions  before  they  start  running.  The  serial  scheduler  is  very  simple  to  understand  and  is 
used  as  the  basis  of  our  correctness  condition. 

We  then  introduce  a  generic  system  to  model  a  system  that  allows  concurrency  and  aborts  of  running 
transactions,  and  uses  some  (unspecified)  concurrency  control  and  recovery  mechanism  for  each  data 
object.  We  use  a  new  sort  of  I/O  automaton  called  a  generic  object,  which  is  like  the  object  automaton  of 
the  serial  system,  but  which  receives  information  about  the  fate  of  transactions  so  that  it  can  continue  to 
respond  correctly  to  invocations  of  operations.  We  also  use  a  different  controller  called  a  generic 
controller,  which  transmits  requests  to  the  appropriate  recipient  with  arbitrary  delay,  allowing  siblings  to 
run  concurrently  or  to  abort  after  performing  some  work.  A  generic  system  is  the  result  of  composing  the 
transaction  automata,  generic  objects  and  generic  controller. 

We  define  a  simple  property  of  generic  objects,  which  we  call  dynamic  atomicity.  Dynamic  atomic 
objects  respond  to  accesses  in  a  way  that  ensures  that  the  accesses  can  be  serialized  in  an  order  that  is 
determined  dynamically  as  the  transactions  return.  We  show  that  if  every  generic  object  in  a  generic 


system  is  dynamic  atomic,  then  the  system  is  correct  in  the  sense  (first  suggested  in  [LM])  that  each 
transaction  that  does  not  have  an  aborted  ancestor  is  unable  to  tell  whether  it  is  running  in  the  generic 
system  or  in  a  corresponding  serial  system.  The  proof  proceeds  by  taking  a  schedule  of  such  a  generic 
system,  choosing  a  subsequence  of  operations  containing  the  operations  of  the  selected  transaction  and  .ill 
the  operations  that  could  have  affected  them,  and  rearranging  that  subsequence  in  any  order  compatible 
with  a  few  simple  conditions.  The  resulting  sequence  is  shown  to  be  a  schedule  of  a  serial  system  that 
appears  the  same  to  the  transaction  chosen.  We  also  define  a  property  called  local-dynamic  atomicity , 
which  implies  dynamic  atomicity,  and  is  more  easily  decidable  from  the  schedules  of  the  object  involved. 

We  next  provide  a  simple  semantic  definition  for  the  key  notion  of  commutativity.  This  definition  in 
turn  relies  on  a  definition  of  cquieffcctive  schedules  to  describe  schedules  that  are  "observation ally 
indistinguishable” .  In  order  to  implement  our  new  locking  algorithm,  we  will  assume  that  for  each  object 
we  are  given  a  table  listing  which  operations  conflict,  and  we  require  that  any  operations  that  do  not 
conflict  be  commutative. 

We  formalize  our  algorithm  for  conflict-baaed  locking  by  constructing  a  Conflict-Based  Locking  object 
W(X)  for  each  basic  object  X.  W(X)  maintains  Sock  tables  and  information  about  previous  operations,  and 
delays  responding  to  invocations  until  the  locking  rules  permit  the  required  locks  to  be  granted.  We 
prove  that  an y  Conflict-Based  Locking  object  is  local-dynamic  atomic.  Thus  a  generic  system  in  which 
every  generic  object  is  a  Conflict-Rased  Locking  object  is  serially  correct.  We  also  show  that  the  R/W 
locking  objects  of  [FLMW],  which  use  Moss’  algorithm  for  concurrency  control,  behave  just  like  Conflict- 
Based  Locking  objects  for  a  suitable  choice  of  conflict  table,  and  are  thus  local-dynamic  atomic. 
Therefore  a  generic  system  where  each  object  is  either  a  R/W  locking  object  or  a  Conflict-Based  Locking 
object  is  serially  correct.  In  particular,  the  correctness  of  a  system  such  as  Argus,  where  every  object  is 
implemented  using  Mass’  algorithm,  follows  from  the  results  in  this  paper. 

There  have  been  several  other  attempts  to  provide  rigorous  proofs  of  the  correctness  of  algorithms  for 
data  management  in  nested  transaction  systems.  The  first  was  |Lyj,  which  presented  a  model  that 
successfully  handled  exclusive  locking,  but  which  proved  difficult  to  extend  to  more  complicated  problems 
such  as  orphan  elimination  (Go).  The  main  deficiencies  of  this  earlier  model  seem  to  be  the  lack  of 
distinction  between  inputs  and  outputs,  and  the  lack  of  explicit  representations  for  transactions  and  their 
interfaces.  These  deficiencies  were  remedied  in  [LMj,  where  the  operational  model  discussed  above  was 
defined;  this  paper  again  proved  correctness  of  exclusive  locking.  Other  work  following  [LM]  includes 
[HLMWj,  (GLj,  [FLMW],  and  [As].  This  paper  continues  the  work  of  [LM]  by  presenting  and  verifying  an 
algorithm  that  allows  arbitrary  types  of  locks.  A  different  program  to  study  concurrency  control  in 
nested  transaction  systems  has  been  offered  m  [BBGLS,BBG],  where  a  major  motivation  is  to  analyze 
protocols  that  operate  on  data  at  different  ley  els  of  abstraction,  but  where  recovery  is  no*,  considered.  The 
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argument  for  the  correctness  of  Moss'  algorithm  in  [BBG]  considers  only  the  locking  rules  and  not  the 
state  maintenance  methods,  so  correctness  is  proved  only  in  the  absence  of  aborts.  Concurrency  control 
and  recovery  algorithms  are  also  analyzed  in  [MGG],  which  is  concerned  mainly  with  levels  of  abstraction. 

This  paper  uses  many  concepts  from  [LM],  but  we  have  repeated  everything  needed  to  make  it  self- 
contained,  and  indicated  where  definitions  or  details  differ. 


2.  I/O  Automata 

The  following  is  a  brief  introduction  to  a  model  that  is  described  in  [LM]  and  developed  at  length,  with 
extensions  to  express  infinite  behavior,  in  [LT]. 

All  components  in  our  systems,  transactions,  objects  and  controllers,  will  be  modelled  by  I/O  automata. 
An  I/O  automaton  A  has  a  set  of  states,  some  of  which  are  designated  as  initial  states.  It  has  operations, 
each  classified  as  either  an  input  operation  or  an  output  operation.  Finally,  it  has  a  transition  relation, 
which  is  a  set  of  triples  of  the  form  (s’,jr,s),  where  s’  and  s  are  states,  and  r  is  an  operation.  This  triple 
means  that  in  state  s’,  the  automaton  can  atomically  do  operation  it  and  change  to  state  s.  An  element  of 
the  transition  relation  is  called  a  step  of  the  automaton.  The  output  operations  are  intended  to  model  the 
actions  that  are  triggered  by  the  automaton  itself,  while  the  input  operations  model  the  actions  that  are 
triggered  by  the  environment  of  the  automaton. 

Given  a  state  s’  and  an  operation  jt,  we  say  that  ir  is  enabled  in  s’  if  there  is  a  state  s  for  which  (s’,jt,s)  is 
a  step.  We  require  the  following  condition: 

Input  Condition:  Each  input  operation  it  is  enabled  in  each  state  s’. 

This  condition  says  that  an  I/O  automaton  must  be  prepared  to  receive  any  input  operation  at  any  time. 

An  execution  of  A  is  an  finite  alternating  sequence  s0,jTj ,Sj,jr2,...,irn,sn  of  states  and  operations  of  A, 
beginning  and  ending  with  a  state.  Furthermore,  sQ  is  a  start  state  of  A,  and  each  triple  (s’,jt,s)  that 
occurs  as  a  consecutive  subsequence  is  a  step  of  A.  From  any  execution,  we  can  extract  the  schedule, 
which  is  the  subsequence  of  the  execution  consisting  of  operations  only.  Because  transitions  to  different 
states  may  have  the  same  operation,  different  executions  may  have  the  same  schedule.  We  say  that  a 
schedule  a  of  A  can  leave  A  in  state  s  if  there  is  some  execution  of  A  with  schedule  a  and  final  state  s. 
We  say  that  an  operation  it  is  enabled  after  a  schedule  a  of  A  if  there  exists  a  state  s  such  that  a  can 
leave  A  in  state  s  and  ir  is  enabled  in  s.  Since  the  same  operation  may  occur  several  times  in  an  execution 
or  schedule,  we  refer  to  a  single  occurrence  of  an  operation  as  an  event. 


We  describe  systems  as  consisting  of  interacting  components,  each  of  which  is  an  I/O  automaton.  It  is 
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convenient  and  natural  to  view  systems  as  I/O  automata,  also.  Thus,  wc  define  a  composition  operation 
for  I/O  automata  to  yield  a  new  I/O  automaton.  A  set  of  I/O  automata  may  be  composed  to  create  a 
system  S  if  the  sets  of  output  operations  of  the  various  automata  are  pairwise  disjoint.  (Thus,  every 
output  operation  in  S  will  be  triggered  by  exactly  one  component.)  A  state  of  the  composed  automaton  is 
a  tuple  of  states,  one  for  each  component,  and  the  start  states  are  tuples  consisting  of  start  states  of  the 
components.  The  operations  of  the  composed  automaton  are  those  of  the  component  automata.  Thus, 
each  operation  of  the  composed  automaton  is  an  operation  of  a  subset  of  the  set  of  component  automata. 
An  operation  is  an  output  of  the  composed  automaton  exactly  if  it  is  an  output  of  some  component.  (The 
output  operations  of  a  system  are  intended  to  be  exactly  those  that  are  triggered  by  components  of  the 
system,  while  the  input  operations  of  a  system  are  those  that  are  triggered  by  the  system’s  environment.) 
During  an  operation  it  of  a  composed  automaton,  each  of  the  components  that  has  operation  Jr  carries  out 
the  operation,  while  the  remainder  stay  in  the  same  state. 

An  execution  or  schedule  of  a  system  is  defined  to  be  an  execution  or  schedule  of  the  automaton 
composed  of  the  individual  automata  of  the  system.  If  a  is  a  schedule  of  a  system  with  component  A, 
then  the  projection  of  a  on  A,  denoted  by  a\A,  is  the  subsequence  of  o  containing  all  the  operations  of  A. 
Clearly,  a\A  is  a  schedule  of  A. 

The  following  lemma  from  [LMj  expresses  formally  the  idea  that  an  operation  is  under  the  control  of  the 
component  of  which  it  is  an  output. 

Lemma  It  Let  a’  be  a  schedule  of  a  system  S,  and  let  a  =  a'n,  where  jr  is  an  output 
operation  of  component  A.  If  ot\A  is  a  schedule  of  A,  then  a  is  a  schedule  of  S. 

Proofs  Since  a\A  is  a  schedule  of  A,  there  is  an  execution  0  of  A  with  schedule  a\A.  Let  0' 
be  the  execution  of  A  consisting  of  all  but  the  last  step  of  0.  Similarly,  since  o’  is  a  schedule 
or  5,  there  is  an  execution  -y  of  S  with  schedule  o’.  It  is  possible  that  A  has  an  execution  in  7 
that  is  different  from  0’,  since  different  executions  may  have  the  same  schedule.  But  it  is  easy 
to  show,  by  induction  on  the  length  of  7,  that  there  is  another  execution  7’  of  S  in  which 
component  A  has  execution  0\  and  which  is  otherwise  identical  to  7,  The  schedule  of  7’  is  o’. 
Since  it  is  not  an  output  operation  of  any  other  component,  jr  is  defined  from  the  state  reached 
at  the  end  of  7’,  so  that  o  =  o’jt  is  a  schedule  of  S.  □ 

We  say  that  automaton  A  preserves  a  property  P  of  schedules  of  A  if  o  =  o’jt  satisfies  P  whenever  o  is 
a  schedule  of  A,  o’  satisfies  P  and  it  is  an  output  of  A. 


3.  Serial  Systems 

In  this  paper  we  define  two  kinds  of  systems:  "serial  systems"  and  "generic  systems".  Serial  systems 
describe  serial  execution  of  transactions.  A  serial  system  is  defined  for  the  purpose  of  giving  a  correctness 
condition  for  other  systems,  namely  that  the  schedules  of  another  system  should  look  like  schedules  of  the 
serial  system  to  the  transactions.  As  with  serial  executions  of  single-level  transaction  systems  serial 
systems  are  too  inefficient  to  use  in  practice.  Thus,  we  will  define  generic  systems,  which  allow 
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transactions  to  run  concurrently  or  abort  after  performing  some  work;  these  systems  use  some  algorithm 
at  each  object  in  order  to  cope  with  the  demands  of  concurrency  control  and  recovery. 

In  this  section  of  the  paper  we  define  serial  systems,  which  consist  of  transaction  automata  and  basic 
object  automata  communicating  with  a  serial  scheduler.  Transactions  and  basic  objects  describe  user 
programs  and  data,  respectively.  The  serial  scheduler  controls  communication  between  the  other 
components,  and  thereby  controls  the  orders  in  which  the  transactions  create  children  or  access  data.  All 
the  system  components  are  modelled  as  I/O  automata.  Most  of  this  section  is  taken  from  [LM],  with 
slight  modifications  to  accomodate  minor  changes  in  definitions. 

We  represent  the  pattern  of  transaction  nesting  by  a  system  type,  which  is  a  set  of  transaction  names, 
together  with  extra  structure  described  below.  We  assume  that  each  possible  instantiation  of  a  piece  of 
program  text  has  its  own  name.  The  transaction  names  are  organized  into  a  tree  by  the  mapping 
"parentQ",  with  T0  as  the  root.  In  referring  to  this  tree,  which  is  part  of  the  system  type,  we  use 
traditional  terminology,  such  as  child,  leaf,  least  common  ancestor  (lea),  ancestor  and  descendant.  (A 
transaction  is  its  own  ancestor  and  descendant.)  Thus  the  children  of  a  transaction  name  are  the  names 
of  all  the  sub-transactions  that  might  ever  be  created  for  it.  The  leaves  of  the  tree  of  transaction  names 
are  called  accesses.  The  accesses  are  partitioned,  where  each  element  of  the  partition  contains  the 
accesses  to  a  particular  object.  We  denote  the  element  of  the  partition  containing  the  accesses  to  object  X 
by  accesses(X).  The  partition,  including  the  names  of  the  objects,  is  part  of  the  system  type. 

The  system  type  can  be  thought  of  as  a  predefined  naming  scheme  for  all  possible  transaction 
instantiations  that  might  ever  be  created,  indicating  for  each  instantiation  the  transaction  of  which  it  is  a 
subtransaction,  and  also  indicating  (for  those  transactions  that  are  accesses)  the  name  of  the  object  being 
accessed.  In  any  particular  execution,  however,  only  some  of  these  transactions  will  actually  take  steps. 
We  assume  that  the  tree  structure  is  known  in  advance  by  all  components  of  a  system.  The  tree  will,  in 
general,  be  an  infinite  structure  with  infinite  branching. 

The  root  transaction  TQ  plays  a  special  role  in  this  theory.  The  root  models  the  environment  of  the 
nested  transaction  system  (the  "external  world")  from  which  requests  for  transactions  originate  and  to 
which  the  results  of  these  transactions  are  reported.  Since  it  has  no  parent,  TQ  may  neither  commit  nor 
abort.  The  classical  transactions  of  concurrency  control  theory  (without  nesting)  appear  in  our  model  as 
the  children  of  T0.  (In  other  work  on  nested  transactions,  such  as  Argus,  the  children  of  T0  are  often 
called  "top-level"  transactions.)  Even  in  the  context  of  classical  theory  (with  no  additional  nesting)  it  is 
convenient  to  introduce  the  root  transaction  to  model  the  environment  in  which  the  rest  of  the 
transaction  system  runs,  with  operations  that  describe  the  invocation  and  return  of  the  classical 
transactions.  It  is  natural  to  reason  about  TQ  in  the  same  way  as  about  all  of  the  other  transactions. 


The  only  transaction*  that* actuary access  data  are  the  leaves  of  tte  transaction  tree*  and  time  they  are 
distinguished  as  "accesses".  The  iMemai  nodes  of  the  tree  model  transactions  whose  function  is  to  create 
and  manage  subtfansaetions,  but' not  to  aecess  datfc  directly. 

We  also  assume  that  a  system  type  includes  a  designated  set  V  of  uafttce,  to  be  used  aa  return  values  of 
transactions. 

A  serial  system  of  a  given  system  type  is  the  composition  of  a  setoM/O  automata.  This  set  contains  a 
transaction  automaton  for  each  internal  (i.e.  non- leaf,  non-access)  node  of  the  transaction  tree,  a  basic 
object  automaton  for  each  object,  arid  a-  serial  scheduler.  These  automata  are  described  below. 
Naturally,  a  practical  system  would  not  Wish  to  have  a  separate  process  pre-existing' for  every  passible 
instantiation  of  a  piece  of  code,  but  would  rather  create  processes  dynamically  as  they  are  needed.  For 
reasoning  about  the  system,  though,  it  is  cleaner  to  model  each  instantiation  separately  as  a  permanent 
entity,  with  an  operation  to  wake  it  up  when  it  gets  “created". 

3.1.  Transactions 

This  paper  differs  from  other  Work  such  as  [BBG]  in  that  we  model  the  transactions  explicitly.  A  non- 
access  transaction  T  is  modelled  as  an  I/O  automaton,  with  (he  following  operations. 

Input  operations: 

CREATE(T) 

REPORT_COMMITfT’,v),  for  T’  a  child  of  T,  and  v  a  value 

REPORT  _  ABOftT(T’),  for  f’  a  child  of  T 

Output  operations: 

REQUEST _  CREATE(T’),  for  T’  a  child  of  T 

REQUEST  _COMMIT(T,v),  for  v  a  value 

The  CREATE  input  operation  "wakes  up"  the  transaction.  The  REQUEST _ CREATE  output 
operation  is  a  request  by  T  to  create  a  particular  child  transaction.8  The  REPORT  _  COMMIT  input 
operation  reports  to  T  the  successful  completion  of  one  of  its  children,  and  returns  a  value  recording  the 
results  of  that  child’s  execution.  The  REPORT _ ABORT  input  operation  reports  to  T  the  unsuccessful 
completion  of  one  of  its  children,  without  returning  any  other  ioformation.  We  call 

REPORT _ COMMlT(T\v),  for  any  v,  and  REPORT_ABORT(T’)  report  operations  for  transaction  T’. 

The  REQUEST  _  COMMIT  operation  is  an  announcement  by  T  that  it  has  finished  its  work,  and  includes 
a  value  recording  the  results  of  that  Work. 


Note  that  there  Is  ho  provision  Tor  T  to  psss  information  to  Its  child  In  this  request.  In  a  programming  language,  t  might  be 
permitted  to  pass  pSrametVV  v Sines  to  a  suM.rsnssctVon  Although  this  may  he  s  corn  entem  lescriptire  aid,  it  ia  not  ne.«aaary  to 
include  it  in  the  underlying  form  SI  model.  Instead,  we  consider  transactions  that  hsre  different  input  parameter*  to  be  different 
transactions. 
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It  is  important  to  note  that  we  use  two  separate  operations,  REQUEST  _  CREATE  and  CREATE,  to 
describe  what  takes  place  when  a  subtransact  ion  is  activated.  The  REQUEST  _  CREATE  is  an  operation 
of  the  transaction’s  parent,  while  the  actual  CREATE  takes  place  at  the  subtransaction  itself.  In  actual 
systems  such  as  Argus,  this  separation  does  occur,  and  the  distinction  will  be  important  in  our  results  and 
proofs.  Similarly,  we  distinguish  between  a  subtransaction’s  REQUEST _  COMMIT,  the  actual  COMMIT 
(which  is  internal  to  the  controller  -  see  Section  3.3),  and  the  REPORT_ COMMIT  operation  of  the 
parent  transaction.7 


We  leave  the  details  of  particular  transaction  automata  largely  unspecified;  in  each  system  the  choice  of 
an  automaton,  that  is  the  choice  of  which  children  to  create,  and  what  value  to  return,  will  depend  on  the 
particular  piece  of  user  code  being  modeled.  For  the  purposes  of  the  controllers  studied  here,  the 
transactions  (and  in  large  part,  the  objects)  are  "black  boxes."  Nevertheless,  it  is  convenient  to  assume 
that  schedules  of  transaction  automata  obey  certain  syntactic  constraints.  We  therefore  require  that  all 
transaction  automata  preserve  well-formedness,  as  defined  in  the  next  paragraph.  We  do  not  constrain 
how  transaction  automata  behave  once  well-formedness  has  been  violated,  but  we  will  prove  later  that  a 
transactions  generate  only  well-formed  schedules  when  placed  in  any  of  the  systems  we  consider. 

We  recursively  define*  wtll-JormedncaB  for  sequences  of  operations  of  transaction  T.  Namely,  the  empty 
schedule  is  well-formed.  Also,  if  a  —  a’ir  is  a  sequence  of  operations  of  T,  where  w  is  a  single  event,  then 
a  is  well-formed  provided  that  o’  is  well-formed,  and  the  following  hold. 

•  If  ir  is  CREATE(T),  then 

(i)  there  is  no  CREATE(T)  event  in  a’. 

•  If  ir  is  REPORT_COMMIT(T’,v)  for  a  child  T’  of  T,  then 

(i)  REQUEST  _CREATE(T’)  appears  in  o’  and 

(ii)  there  is  no  REPORT  _ABORT(T’)  event  in  a’  and 

(iii)  there  is  no  REPORT_COMMIT(T’,v’)  event  with  v’y^v  in  o’. 

•  If  ir  is  REPORT  _  ABORT(T’)  for  a  child  T’  of  T,  then 

(i)  REQUEST _CREATE(T’)  appears  in  a’  and 

(ii)  there  is  no  REPORT_COMMIT  event  for  T’  in  o’. 

•  If  *  is  REQUEST  _CREATE(T’)  for  a  child  T’  of  T,  then 

(i)  there  is  no  REQUEST  _CREATE(T’)  event  in  o’  and 

(ii)  there  is  no  REQUEST _ COMMIT  event  for  T  in  o’  and 


Note  that  we  do  sot  include  a  REQUEST _  ABORT  operation  for  a  transaction:  we  do  not  model  the  situation  in  which  a 
transaction  decides  that  its  own  existence  is  a  mistake.  Rather,  we  assign  decisions  to  abort  transactions  to  another  component  of 
the  system,  the  controller.  In  practice,  the  controller  must  hare  some  power  to  decide  to  abort  transactions,  as  when  it  detects 
deadlocks  or  failures.  In  Argus,  transactions  are  permitted  to  request  to  abort;  we  regard  this  request  simply  at  a  ‘hint*  to  the 
controller,  to  restrict  its  allowable  executions  in  a  particular  way. 

*Th  is  definition  is  more  restrictive  than  that  in  |LM|,  where  a  REQUEST _  COMMIT  was  allowed  whenever  the  transaction  had 
been  created  and  bad  not  requested  to  commit. 
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(iii)  CREATE(T)  appeals  in  a’. 

•  If  jr  is  REQUEST _COMMlT(T,v)  for  a  value  v,  then 

(i)  there  is  no  REQUEST  ^COMMIT  event  for  T  in  o’  and 

(ii)  CREATE(T)  appears  in  cr’  and 

(iii)  there  is  a  report  event  in  a’  for  every  child  of  T  for  which  there  is  a 

REQUEST  _  CREATE  event  in  a’. 

These  restrictions  are  very  basic;  they  simply  say  that  a  transaction  does  not  get  created  more  than 
once,  does  not  receive  conflicting  information  about  the  fates  of  its  children,  and  does  not  receive 
information  about  the  fate  of  any  child:  whose  creation  it  has  not  requested;  also,  a  transaction  does  not 
perform  any  output  operations  before  it  has  been  created  or  after  it  has  requested  to  commit,  it  does  not 
request  the  creation  of  the  same  child  more  than  onee,  and  it  deee  not  request  to  commit  until  it  has 
received  information  about  the  fate-  of  every  child  whose  creation  it  requested.  Except  for  these  minimal 
conditions,  there  are  no  a  priori  restrictions  on  allowable  transaction  behavior. 


The  following  easy  lemma  summarizes  the  properties  of  well-formed  sequences  of  transaction  operations.  ' 
Lemma  2i  Let  a  be  a  well-formed  sequence  of  operations  of  transaction  T.  Then  the 
following  conditions  hold. 

1.  The  first  event  in  a  is- a  CREATE(T)  event,  and  there  are  no  other  CREATE  events. 

2.  There  is  at  most  one  REQUEST _  CREATE{ T’)  event  in  a  for  each  child  T*  of  T. 

3.  There  are  not  two  different  report’  operations  in  a  for  any  child  T’  of  T.  (However> 
there  may  be  several  events  that  are  repeated  instances  of  a  single  report  operation). 

4.  Any  report  event  for  a  child  T’  of  T  is  preceded  by  REQUEST ^^REATE^T’)  in  or. 

5.  If  a  REQUEST _  COMMIT  event  for  T  occurs  in  a,  then  there  are  no  later 
REQUEST  _  CREATE  or  REQUEST  _  COMMIT  events  of  T  in  a. 

6.  If  a  REQUEST  _  COMMIT  event  for  T  occurs  in  a,  then  it  is  preceded  by  a  report 
event  for  each  child  of  T  whose  creation  is  requested  in  a. 

Conversely,  any  sequence  of  operations  of  T  satisfying  these  conditions  is  weth-formed. 


3.2.  Basic  Objects 

Recall  that  I/O  automata  are  associated  with  non-access  transactions  only.  Since  access  transactions 
model  abstract  operations  on  shared  data  objects,  we  associate  a  single  I/O  automaton  with  each  object, 
rather  than  one  for  each  access.  The  operations  for  each  object  are  just  the  CREATE  and 
REQUEST  _  COMMIT  operations  for  all  the  corresponding  access  transactions.  Although  we  give  these 
operations  the  same  sorts  of  names  as  the  operations  of  non-access  transactions,  it  is  helpful  to  think  of 
the  operations  of  access  transactions  in  other  terms  also:  a  CREATE  corresponds  to  an  invocation  of  an 
operation  on  the  object,  while  a  REQUEST _ COMMIT  corresponds  to  a  response  by  the  object  to  an 
invocation.  One  should  notice  though  that  these  CREATE  and  REQUEST _ COMMIT  operations  carry 
with  them  a  designation  of  the  position  of  the  access  in  the  transaction  tree.  Thus,  a  haste  object  X  is 
modelled  as  an  automaton,  with  the  following  operations. 

Input  operations: 


ii 


CREATE(T),  for  T  an  access  to  X 

Output  operations: 

REQUEST  _  COMMIT(T,v),  for  T  an  access  to  X 

Our  model  differs  significantly  from  other  common  models  used  to  reason  about  data,  in  that  we  do  not 
insist  that  the  object  have  a  value  (of  the  type  returned  by  a  read  operation)  at  all  times.  We  do  not 
specify  any  particular  relationship  between  the  internal  state  of  the  object  automaton  and  the  values 
returned  by  accesses,  and  it  is  only  the  values  returned  that  matter  to  transactions  in  the  system. 

As  with  transactions,  while  specific  objects  are  left  largely  unspecified,  it  is  convenient  to  require  that 
schedules  of  basic  objects  satisfy  certain  syntactic  conditions.  Thus  each  basic  object  is  required  to 
preserve  well-formedness,  as  defined  below. 


Let  a  be  a  sequence  of  events  of  a  basic  object.  Then  an  access  T  to  X  is  said  to  be  pending  in  a 
provided  that  a  contains  CREATE(T)  but  no  REQUEST  _  COMMIT  event  for  T.  We  recursively  define 
w ell-formedneae  for  sequences  of  operations  of  basic  objects.  Namely,  the  empty  schedule  is  well-formed. 
Also,  if  o  =  o’ir  is  a  sequence  of  operations  of  basic  object  X,  where  it  is  a  single  event,  then  a  is  well- 
formed  provided  that  a’  is  well-formed,  and  the  following  hold. 

•  If  it  is  CREATE(T),  then 

(i)  there  is  no  CREATE(T)  event  in  o’,  and 

(ii)  there  are  no  pending  accesses  in  or’. 

•  If  jt  is  REQUEST_COMMIT(T,v)  for  a  value  v,  then 

(i)  there  is  no  REQUEST  _  COMMIT  event  for  T  in  a’,  and 

(ii)  CREATE(T)  appears  in  o’. 

These  restrictions  simply  say  that  the  same  access  does  not  get  created  more  than  once,  nor  does  the 
creation  of  a  new  access  occur  before  any  previous  access  has  completed  (i.e.  requested  to  commit);  also,  a 
basic  object  does  not  respond  more  than  once  to  any  access,  and  only  responds  to  accesses  that  have 
previously  been  created. 


The  following  easy  lemma  summarises  the  properties  of  well-formed  sequences  of  basic  object 
operations. 

Lemma  3:  Let  or  be  a  well-formed  sequence  of  operations  of  basic  object  X.  If  a  contains  an 
even  number  of  events,  then  or  is  the  concatenation  of  a  sequence  of  pairs 
CREATE(T.)REQUEST_COMMIT(Tj,v.),  with  T.  yt  T.  when  i  y^  j.  If  a  contains  an  odd 
number  of  operations,  then  a  is  the  concatenation  of  a  sequence  of  pairs 
CREATE(Ti)REQUEST_COMMIT(T.,vi)  followed  by  a  single  CREATE^’),  with  T.  yk  T. 
when  i  yL  j,  and  T’  y&  T..  Conversely  any  sequence  or  of  operations  of  X  that  satisfies  either  of 
these  descriptions  is  well-formed. 


We  will  often  have  occasion  to  refer  to  a  pair  of  operations  CREATE(T)REQUEST_COMMIT(T,v). 
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REPORT  _COMMlT{T)v)(  T  /  T0 
Precondition: 

T  €  s’. commit  ted 

(T,v)  €  s’.eommit_  requested 

The  input  operations,  REQUEST  __  CREATE)  and  REQUEST _ COMMIT,  simply  result  in  die  request 

being  recorded.  A  CREATE  operation  can  occur  only  if  a  corresponding  REQUEST _ CREATE  has 
occurred  and  the  CREATE  has  not  already  occurred.  The  second  precondition  on  die  CREATE 
operation  says  that  the  serial  scheduler  does  not  create  a  transaction  until  all  its  previously  created  sibling 
transactions  have  returned.  That  is,  siblings  are  run  sequentially.  The  preconditions  on  the  ABORT 
operation  say  that  the  serial  scheduler  does  not  abort  a  transaction  while  any  of  its  siblings  are  active  or 
if  the  transaction  has  already  been  created.  That  is,  aborted  transactions  take  no  steps  and  are  dealt 
with  sequentially  with  respect  to  their  siblings.  The  result  of  a  transaction  can  be  reported  to  its  parent 
at  any  time  after  the  (purely  internal)  commit  or  abort  has  occurred.  In  particular,  willing*  might  run  in 
one  order  and  be  reported  to  their  parent  in  some  other  order.® 

The  next  lemma  relates  a  schedule  of  die  serial  scheduler  to  the  state  that  results  from  applying  that 

schedule. 

Lemma  4:  Let  or  be  a  schedule  of  the  serial  scheduler,  and  let  s  be  a  state  that  can  result 
from  applying  a  to  the  initial  state.  Then  the  following  conditions  are  true. 

1.  T  is  in  s.creaite  _  requested  exactly  if  T  *=  T#  or  a  contains  a  REQUEST  __  CStSATE^T) 
event. 

2.  T  is  in  s.created  exactly  if  a  contains  a  CREATE(T)  event. 

3.  (T,v)  is  in  s.commit_  requested  exactly  if  a  contains  a  REQUEST  _  CJOMMTr(T,v) 
event. 

4.  T  is  in  s.committed  exactly  if  a  contains  a  COMMIT(T)  event. 

5.  T  is  in  s.aborted  exactly  if  or  contains  an  ABORT(T)  event. 

6.  s. returned  =  s.committed  U  s.aborted. 

7.  s.committed  D  s.aborted  =  0. 

3.4.  Serial  Systems  and  Serial  Schedules 

The  composition  of  transactions  with  basic  objects  and  the  serial  scheduler  for  a  given  system  type  is 
called  a  serial  system,  and  its  operations  and  schedules  are  called  serial  operations  and  serial  schedules, 
respectively.  We  note  that  every  serial  operation  is  an  operation  of  the  serial  scheduler  and  of  at  most 
one  other  component  of  the  serial  system.  A  sequence  <*  of  serial  operations  is  said  to  be  well-formed 
provided  that  its  projection  at  every  transaction  and  basic  object  is  well-formed. 


90n«  significant  difference  between  our  serial  scheduler  and  the  one  in  |LM|  is  that  these  the  return  operation  and  the  report  to 
the  parent  of  the  return  are  combined  as  a  single  operation,  giving  tin  parent  the  extra  information  of  the  order  in  wuieh  iu  children 
are  run.  Another  difference  is  that  In  (LM]  the  serial  scheduler  prevented  a  transaction  from  committing  unless  every  child  whose 
creation  was  requested  had  returned,  since  in  that  paper  the  transactions  were  not  required  to  enforce  this  themselves. 
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If  a  is  a  sequence  of  operations  and  T  is  a  transaction  such  that  a  contains  CREATE(T)  but  no  return 
event  for  T,  we  say  that  T  is  live  in  a.  The  following  are  useful  observations: 

Lemma  5:  Let  a  be  a  well-formed  serial  schedule,  T  a  transaction  live  in  a  and  T’  an 
ancestor  of  T.  Then  T’  is  live  in  a. 

Lemma  6:  Let  a  be  a  well-formed  serial  schedule,  and  T  and  T’  distinct  sibling 
transactions.  If  T  is  live  in  a,  then  T*  is  not  live  in  a. 

A  consequence  of  the  two  previous  lemmas  is  the  following,  which  states  that  transactions  can  be  live 

concurrently  in  a  well-formed  serial  schedule  only  if  one  is  an  ancestor  of  the  other. 

Lemma  7:  Let  a  be  a  well-formed  serial  schedule,  and  T  and  T’  transactions  each  of  which 
is  live  in  a.  Then  either  T  is  an  ancestor  of  T’  or  T’  is  an  ancestor  of  T. 


We  now  show  that  all  serial  schedules  are  well-formed.  Afterwards,  we  will  use  this  fact  repeatedly, 

without  explicitly  noting  it  or  referencing  this  lemma. 

Lemma  8<  Let  or  be  a  serial  schedule.  Then  a  is  well-formed. 

Proof:  By  induction  on  the  length  of  schedules.  The  base,  length  =  0,  is  trivial.  Suppose 
that  ax  is  a  serial  schedule,  and  assume  that  a  is  well-formed.  If  n  is  an  output  of  a  basic 
object  or  non-access  transaction  P,  then  ax|P  is  well-formed  because  P  preserves  well- 
formedness,  and  so  ax  is  well-formed.  So  assume  that  n  is  an  output  operation  of  the  serial 
scheduler.  If  n  is  a  return  operation  for  a  transaction,  it  is  not  an  operation  of  any  basic 
object  or  non-access  transaction  automata,  so  ax  is  well-formed,  since  ax|P=a|P  for  all  basic 
object  or  non-access  transaction  automata  P.  The  remaining  cases  are  when  x  is  an  input 
operation  of  some  basic  object  or  non-access  transaction  automaton  P.  It  suffices,  in  each  case, 
to  show  that  ax|P  is  well-formed. 

(1)  x  is  CREATE(T)  for  some  non-access  transaction  T. 

The  serial  scheduler  preconditions  and  Lemma  4  ensure  that  CREATE(T)  does  not  appear  in 
a. 


(2)  x  is  CREATE(T)  for  some  access  T  to  basic  object  X. 

The  serial  scheduler  preconditions  and  Lemma  4  ensure  that  CREATE(T)  does  not  appear  in 
a.  Well-formedness  of  a  at  X  implies  therefore  that  a  does  not  contain  a 
REQUEST _ COMMIT  event  for  T,  and  thus  that  T  is  pending  in  a.  By  Lemma  7  we  deduce 
that  no  transactions  except  ancestors  of  T  are  live  in  a,  and  in  particular,  no  other  access  to  X 
is  live  in  a.  Any  pending  access  T’  in  a  must  be  live,  as  a  cannot  contain  a  COMMIT  event 
for  T’  without  also  containing  a  REQUEST  _  COMMIT  event  for  T\  and  a  cannot  contain  an 
ABORT  event  for  T  as  well  as  a  CREATE  event  for  T\  Thus  no  access  to  X  other  than  T  is 
pending  in  a. 

(3)  x  is  REPORT_COMMIT(T,v)  for  some  transaction  T  and  value  v. 

Then  x  is  an  input  to  transaction  parent(T)  =  T\  The  serial  scheduler  preconditions  and 
Lemma  4  imply  that  a  contains  REQUEST  _COMMIT(T,v).  Well-formedness  of  a  at  the 
non-access  transaction  T  (or  at  basic  object  X,  if  T  is  an  access  to  X)  implies  that  a  contains 
CREATE(T),  and  the  serial  scheduler  preconditions  and  Lemma  4  then  require  that  a  contains 
REQUEST  _CREATE(T).  Also,  serial  scheduler  preconditions  and  Lemma  4  imply  that 
COMMIT(T)  occurs  in  a,  and  thus  no  AB0RT(T)  occurs  in  a.  Thus  no 
REPORT_ABORT(T)  occurs  in  a,  by  the  serial  scheduler  preconditions.  Well-formedness  at 
T  (or  at  X,  if  T  is  an  access  to  X)  implies  that  no  REQUEST _C0MMIT(T,v’)  with  v’  yd  v 
occurs  in  a,  and  therefore  by  the  serial  scheduler  preconditions,  no  REPORT_COMMlT(T,v’) 
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with  v’  jL  v  occurs  in  a. 

(4)  n  is  REPORT  _ ABORT(T)  for  some  transaction  T. 

Then  ir  is  an  input  to  transaction  parent(T)  =  T\  The  serial  scheduler  preconditions  and 
Lemma  4  imply  that  a  contains  ABORT(T)  and  hence  contains  REQUEST  _  OREATE(T)  but 
no  CREATE(T).  The  analysis  above  shows  that  this  is  incompatible  with  the  presence  of  anv 
REPORT _ COMMIT  event  for  T.  □ 


3.6.  Visibility 

In  order  to  talk  about  schedules,  we  introduce  some  terms  to  describe  the  fate  of  transactions.  Let  a  be 
any  sequence  of  operations.  (We  will  use  these  same  terms  later  for  schedules  of  generic  systems,  so  we 
make  the  definitions  for  general  sequences.)  If  T  is  a  transaction  and  T'  an  ancestor  of  T,  we  say  that  T 
is  committed  to  T*  in  a  if  COMMIT(U)  occurs  in  a  for  every  U  that  is  an  ancestor  of  T  and  a  proper 
descendant  of  T’.  If  T  and  T’  are  transactions  we  say  that  T  is  visible  to  T*  in  o  if  T  is  committed  to 
lca(T,T’). 

We  also  introduce  two  terms  that  describe  different  relationships  between  events  and  transactions  We 
will  always  associate  an  operation  of  a  noa-acess  transaction  automaton  with  that  transaction  The  return 
operation  for  a  transaction  (which  occurs  only  at  the  controller)  will  sometraM*  need  to  be  associated  with 
the  transaction,  and  sometimes  with  the  parent  the  transaction.  If  jr  is  one  of  the  operations 
CREATE(T),  REQUEST  _CREATE(T’),  REPORT  _  CXJMMITfr.v’),  REPORT_ABORT(T\v’), 
REQUEST _  COMMIT(T ,v),  COMMIT(T),  or  ABQRT(T),  where  T’  is  a  child  of  T,  we  say  that  a 
mentions  T.  Thus  if  T  is  a  aoa- access  transaction  then  the  operations  that  mention  T  are  the  operations 
of  the  automaton  T  together  with  the  return  operations  for  T.  If  a  is  one  of  the  operations  CREATE(T), 
REQUEST  _  CREATEfT’),  OOMMIT(T’),  ABORT(T’),  REPORT_OOMMIT(r,V’), 
REPORT_ABORT(T’,v’),  or  REQUEST _OOMMIT(T,v),  where  T’  is  a  child  of  T,  then  we  define 
transaction^ )  to  be  T  .  If  T  is  a  non-access  transaction  then  the  operations  a  with  traasaction(a)  »  T  are 
the  operations  of  the  automaton  T  together  with  the  return  operations  for  children  of  T.  We  denote  by 
visible(a,T)  the  subsequence  of  a  consisting  of  events  a  with  transaction(a)  visible  to  T  in  a.  Notice  that 
every  operation  occurring  in  viaible(a,T)  is  a  serial  operation,  even  if  a  itself  contains  other  operations. 


We  collect  here  some  straightforward  consequences  of  these  definitions: 

Lemma  ft  Let  o  be  a  sequence  of  operations,  and  T,  T’  and  T”  transactions. 

1.  If  T  is  an  ancestor  of  T\  then  T  is  visible  to  T’  in  a. 

2.  T’  is  visible  to  T  in  a  if  and  only  if  T’  is  visible  to  lca(T,T’)  in  a. 

3.  If  T”  is  visible  to  T’  in  o  and  T’  is  visible  to  T  in  a,  then  T”  is  visible  to  T  in  a. 

4.  If  T*  is  a  proper  descendant  of  T,  T”  is  visible  to  T’  in  o,  but  T”  is  not  visible  to  T  in 
a,  then  T”  is  a  descendant  of  the  child  of  T  that  is  an  ancestor  of  T’. 

Lemma  10*  Let  o  and  $  be  sequences  of  operations  such  that  fl  consists  of  a  subset  of  the 
events  of  a. 

1.  If  transaction  T  is  visible  to  transaction  T’  in  $,  then  T  is  visible  to  T’  in  er. 
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2.  If  event  jt  is  in  visible{0,T),  then  ir  is  in  visible(a,T). 

Lemma  lit  Let  a  be  &  sequence  of  operations,  and  let  T  and  T’  be  transactions.  Then 
visible(a,T)|T’  is  equal  to  a|T’  if  T’  is  visible  to  T  in  a,  and  is  equal  to  the  empty  sequence 
otherwise. 

Lemma  12:  Let  a  be  a  sequence  of  operations.  Let  T,  T’  and  T”  be  transactions  such  that 
T”  is  visible  to  T’  and  to  T  in  a.  Then  T”  is  visible  to  T’  in  visible(ar,T). 

Lemma  13:  Let  T  be  a  transaction,  and  let  an  be  a  sequence  of  operations,  where  n  is  a 
single  event. 

1.  If  transaction! s’)  is  not  visible  to  T  in  an,  then  visible(aJr,T)  =  visible(a,T). 

2.  If  transaction!  »r)  is  visible  to  T  in  o*  and  if  n  is  not  a  COMMIT  event,  then 
visible!ajr,T)  =  visible{a,T)jr. 

3.  If  transaction!  *)  is  visible  to  T  in  an,  and  n  is  COMMIT(U)  then  the  events  in 
viaible(a]r,T)  are  those  visible  in  a  to  either  T  or  U,  together  with  n  itself. 


Let  a  be  any  sequence  of  operations.  If  T  is  a  transaction  we  say  T  is  an  orphan  in  a  if  ABORT{U) 

occurs  in  a  for  some  ancestor  U  of  T.  The  following  lemmas  are  straightforward. 

Lemma  14:  Let  a  and  0  be  sequences  of  operations  such  that  $  consists  of  a  subset  of  the 
events  in  a.  If  a  transaction  T  is  not  an  orphan  in  a  then  T  is  not  an  orphan  in  0. 

Lemma  15:  Let  a  is  a  sequence  of  operations.  If  T  is  a  transaction  that  is  not  an  orphan  in 
a  and  T’  is  an  ancestor  of  T,  then  T’  is  not  an  orphan  in  a. 


3.8.  Serial  Correctness 

We  use  serial  schedules  as  the  basis  of  our  correctness  definition,  which  was  first  given  in  [LMj. 
Namely,  we  say  that  a  sequence  of  operations  is  aerially  correct  for  a  traneaction  T  provided  that  its 
projection  on  T  is  identical  to  the  projection  on  T  of  some  serial  schedule.  That  is,  the  sequence  "looks 
like"  a  serial  schedule  to  T.  Later  in  this  paper  we  will  define  "Conflict-Based  Locking  systems"  and  show 
that  their  schedules  are  serially  correct  for  every  non-orphan  transaction,  and  in  particular  that  these 
schedules  are  serially  correct  for  the  root  transaction  TQ. 

Motivation  for  our  use  of  serial  schedules  to  define  correctness  derives  from  the  simple  behavior  of  the 
serial  scheduler,  which  determines  the  sequence  of  interactions  between  the  transactions  and  objects.  We 
believe  the  depth-first  traversal  of  the  transaction  tree  to  be  a  natural  notion  of  correctness  that 
corresponds  precisely  to  the  intuition  of  how  nested  transaction  systems  ought  to  behave.  Furthermore,  it 
is  a  natural  generalization  of  serializability,  the  correctness  condition  generally  chosen  for  classical 
transaction  systems.  Serial  correctness  for  T  is  a  condition  that  guarantees  to  implementors  of  T  that 
their  code  will  encounter  only  situations  that  can  arise  in  serial  executions.  Correctness  for  TQ  is  a  special 
case  that  guarantees  that  the  external  world  will  encounter  only  situations  that  can  arise  in  serial 
executions. 

It  would  be  best  if  every  transaction  (whether  an  orphan  or  not)  saw  data  consistent  with  a  serial 
execution.  Ensuring  this  requires  a  much  more  intricate  controller  than  the  simple  generic  systems  we 


18 


describe  below.  In  [HLMW],  several  algorithms  for  maintaining  correctness  for  orphan  transactions  are 
described  and  verified. 

Our  approach  is  an  example  of  a  general  technique  for  studying  system  algorithms.  A  simple,  intuitive 
but  inefficient  or  impractical  algorithm  (automaton)  is  used  to  specify  an  acceptable  collection  of 
schedules  for  the  system  component.  The  actual  system  component  is  more  efficient  or  robust,  but 
provides  the  same  user  interface.  The  user  is  guaranteed  that  applications  (transactions,  in  our  work) 
that  work  well  when  run  with  the  simple  algorithm  will  work  the  same  way  when  run  with  the  actual 
system. 


4.  Generic  Systems 

The  serial  systems  described  in  the  previous  section  have  a  restrictive  controller  (the  serial  scheduler) 
that  makes  their  behavior  easy  to  reason  about,  but  also  makes  them  a  poor  choice  for  implementation. 
Practical  systems  allow  activity  to  procede  concurrently  in  sibling  transactions  to  improve  performance, 
and  therefore  need  to  use  complicated  algorithms  at  the  objects  to  ensure  that  the  resulting  behavior  is 
still  serially  correct.  In  this  section,  we  introduce  a  generic  system,  which  is  composed  of  transactions  (just 
like  a  serial  system),  generic  objects  (each  of  which  receives  information  about  commits  and  aborts  of 
transactions,  and  uses  an  as  yet  unspecified  concurrency  control  algorithm),  and  a  generic  controller 
(which  allows  concurrency  and  aborts  of  running  transactions).  In  Theorem  *2,  we  will  give  a  simple 
condition  on  the  generic  objects  that  ensures  that  the  generic  system  is  serially  correct. 

4.1.  Generic  Objects 

For  each  object  X  in  the  system  type,  a  generic  system  must  include  a  generic  object  automaton.  The 
operations  of  a  generic  object  X  are: 

Input  operations: 

CREATE(T),  T  an  access  to  X 

INFORM  _  COMMIT_  AT(X)OF(T) 

INFORM  _  ABORT  _  AT(X)OF(T) 

Output  operations: 

REQUEST  __  COMMIT( T, v),  T  an  access  to  X 

We  give  a  recursive  definition  for  wcti-formednete  of  schedules  of  generic  object  X.  Namely,  the  empty 
schedule  is  well-formed.  Also,  if  a  =  o'r  is  a  sequence  of  events  of  generic  object  X,  then  o  is  well- 
formed  provided  that  o’  is  well-formed  and  the  following  hold. 

•  If  jt  is  CREATE(T),  then 

(i)  there  is  no  CREATE(T)  in  o’. 

•  If  7T  is  a  REQUEST  _  COMMIT  for  T,  then 

(i)  there  is  no  REQUEST _ COMMIT  for  T  in  o’,  and 
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(ii)  CREATE(T)  occurs  in  or’. 

•  If  jt  is  INFORM_COMMIT_AT(X)OF{T),  then 

(i)  there  is  no  INFORM  _  ABORT  _AT(X)OF(T)  in  o’,  and 

(ii)  if  T  is  an  access  to  X,  then  a  REQUEST  _  COMMIT  for  T  occurs  in  o'. 

•  If  *  is  INFORM  _ ABORT  _AT(X)OF(T),  then 

(i)  there  is  no  INFORM  _  COMMIT  _AT(X)OF(T)  in  o’. 

Generic  objects  are  required  to  preserve  well-formedness. 

Each  generic  object  represents  a  data  item,  together  with  the  concurrency  control  and  recovery 
algorithms  used  to  maintain  it.  Thus  our  model  is  particularly  convenient  for  representing  systems  in 
which  different  data  items  are  maintained  with  different  concurrency  control  algorithms,  as  can  easily 
happen  in  a  distributed  database  formed  by  combining  pre-existing  databases.  It  is  well  known  that 
different  correct  algorithms  cannot  always  be  combined.  For  example,  a  system,  in  which  some  data  items 
are  maintained  with  timestamps  and  others  use  two-phase  locking,  may  not  guarantee  serializability.  In 
this  paper  we  will  introduce  a  property  called  dynamic  atomicity.  We  will  show  that  so  long  as  every 
generic  object  in  the  system  is  dynamic  atomic,  then  the  whole  system  generates  serially  correct  schedules. 

4.2.  Generic  Controller 

The  generic  controller  is  a  nondeterministic  automaton.  It  passes  requests  for  the  creation  of  sub¬ 
transactions  or  accesses  to  the  appropriate  recipient,  passes  responses  back  to  the  caller  and  informs 
objects  of  the  fate  of  transactions,  but  it  may  delay  such  messages  for  arbitrary  lengths  of  time  or 
unilaterally  decide  to  abort  a  subtransaction  that  has  been  created.  Moss  [Moj  devotes  considerable  effort 
to  describing  a  distributed  implementation  of  the  controller  that  copes  with  communication  failures  and 
loss  of  system  information  due  to  crashes,  yet  still  commits  a  subtransaction  whenever  possible.  These 
concerns  are  orthogonal  to  the  correctness  of  the  data  management  algorithms  and  we  do  not  address 
them  here.10  We  use  nondeterminism  in  the  generic  controller  so  that  our  results  will  apply  to  many 
different  controllers,  each  implementing  the  generic  controller  by  exhibiting  a  subset  of  the  behaviors 
permitted  by  the  nondeterminism. 

The  generic  controller  has  the  following  operations: 

Input  operations: 

REQUEST  _  CREATE(T) 

REQUEST  _COMMIT(T,v) 

Output  operations: 


**The  generic  controller  ie  limiter  to  the  week  concurrent  controller  of  |LM|.  It  differ*  slightly  in  the  nemes  of  its  operations,  in 
the  separation  of  return  end  report  operations,  end  in  the  conditions  under  which  CREATE  and  COMMIT  operations  are  permitted 
to  occur. 
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CREATE(T) 

COMhflT(T)t  T  yd  T„ 

ABORT(T),  T  yd  T0 
REPORT  _  COhfltflT(T,v)i  T  ^ 

REPORT  _ABORT(T),  T  yd 

INFORM  _  COMMIT  _ ATPQ)0ff|T^  T  yd  T„ 

INFORM_ABORT_ATpC)Or(Ti  T  yd  \ 

These  play  the  same  roles  as  n>  the  serial  scheduler,  with  the  addition,  of  the  ENFORM'__ COMMIT  and 
INFORM  _  ABORT  operations,  which  pass  information  about  the  Cate  of  transactions  to  the  generic 

objects. 

Each  state  s  of  the  generic  controller  consists  of  six  sets:  *. c reate  _  requested,  s.  created, 
s. commit  _  requested,  s.  committed,  s.  aborted  and  a  returned.  The  set  s. commit  _  requested  is  a  set  of 
(transaction, value)  pairs,  and  the  ethers  an  sets  of  transactions.  Ad  are  empty  in  the  uaitial  state  except 
for  create  _  requested,  which  is  (T^J. 


The  operations  are  defined  by  pre-  and  poetcooditioss  aa  follows: 

REQUEST  _  CREATE(T) 

Postcondition: 

s.create_ requested  =  s’.create_ requested  U  {T} 

REQUEST  _  COMMIT(T,v} 

Postcondition: 

s. commit  _  requested  —  s’.commit_ requested  U  {(T,v)) 

CREATE(T),  T  a  transaction 
Precondition: 

T  €  s’. create  _  requested  -  s’ .created 
Postcondition: 

s.created  =  s’. created  U  (T) 

COMMIT(T),  T  yd  T8 
Precondition: 

(T,v)  €  s’.comniit_  requested  for  some  v 
T  ft  s’. returned 

Postcondition: 

s. committed  -=  s’. committed  U  { T} 
s.returned  =*  s’. returned  U  (T) 

ABORT(T),  T  yd  T# 

Precondition: 

T  €  s’. create- requested  •  s’. returned 
Postcondition: 

s  aborted  *  s’. aborted  U  {T} 
s.returned  s’. returned  U  {T} 
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REPORT  _COMMIT(T,v),  T  ^  Tfl 
Precondition: 

T  €  s’.committed 

(T,v)  €  s\commit_  requested 

REPORT_ABORT(T),  T^Tfl 
Precondition: 

T  €  s’.aborted 

INFORM_COMMIT_AT(X)OF(T),  T  /  TQ 
Precondition: 

T  €  s’.committed 

INFORM  _  ABORT  _  AT(X)OF(T),  T  ^  TQ 
Precondition: 

T  6  s’.aborted 

Lemma  16:  Let  a  be  a  schedule  of  the  generic  controller,  and  let  s  be  the  state  that  results 
from  applying  a  to  the  initial  state  sfl.  Then  the  following  conditions  are  true. 

1.  T  is  in  s.create_  requested  exactly  if  T  =  TQ  or  er  contains  a  REQUEST  _  CREATE(T) 
event. 

2.  T  is  in  s.created  exactly  if  a  contains  a  CREATE(T)  event. 

3.  (T,v)  is  in  s.commit_ requested  exactly  if  a  contains  a  REQUEST _COMMIT(T,v) 
event. 

4.  T  is  in  s.aborted  exactly  if  a  contains  an  ABORT(T)  event. 

5.  T  is  in  s.committed  exactly  if  a  contains  a  COMMIT(T)  event. 

6.  s.returned  =  s.committed  U  s.aborted. 

7.  s.committed  D  s.aborted  =  0. 


An  obvious  but  important  property  of  the  generic  controller  is  given  by  the  next  lemma. 

Lemma  17:  If  a  is  a  schedule  of  the  generic  controller  then  a  contains  at  most  one  return 
event  for  each  transaction  T. 

4.3.  Generic  Systems 

A  generic  eyetem  is  the  composition  of  non-access  transaction  automata,  generic  object  automata,  and 
the  generic  controller  automaton.  The  operations  of  a  generic  system  are  called  generic  operations,  and  a 
schedule  of  a  generic  system  is  called  a  generic  schedule.  A  sequence  of  generic  events  is  called 
well-formed  provided  that  its  projection  at  each  non-access  transaction  and  generic  object  is  well-formed. 

We  collect  here  some  straight-forward  properties  of  generic  schedules. 

Lemma  18:  Let  a  be  a  generic  schedule.  Then  a  is  well-formed. 
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Lemma  18:  Let  a  be  a  generic  schedule,  and  T  a  transaction  that  is  uot  an  orphan  in  a.  If 
T’  is  visible  to  T  in  a,  then  T’  is  not  an  orphan  in  a. 

Lemma  Xh  Let  e  be  a  generic  schedule,  and  T  a  transaction  that  is  live  and  not  an  orphan 
in  a.  Then  the  ancestors  of  T  are  all  live  in  o. 

5.  Reordering  Events:  Return  Order  and  the  Affects  Order 

The  correctness  condition  we  seek  to  demonstrate  requires  non-orphan  transactions  to  see  serial 
schedules;  given  a  generic  schedule  a  and  a  non-orphan  transaction  T,  we  wish  to  prove  that  a|T  —  /9|T 
for  some  serial  schedule  0.  To  find  0,  our  strategy  will  be  to  extract  from  a  the  subsequence  visible(a,T), 
which  contains  all  the  operations  at  T,  and  then  reorder  the  events  in  visible(a,T)  to  form  the  new 
sequence  0,  which  we  argue  is  a  serial  schedule  and  looks  to  T  exactly  like  a  provided  the  generic  objects 
all  obey  a  simple  condition. 

Serial  schedules  are  characterised  by  the  depth-first  order  in  which  the  serial  scheduler  runs 
transactions.  This  depth-first  order  can  be  characterized  by  ordering  each  set  of  siblings.  Below,  we 
define  such  an  ordering  to  be  a  "sibling  order,"  and  focus  attention  on  the  sibling  order  induced  by  the 
order  of  return  events  in  the  generic  schedule  or.  As  we  will  see,  this  is  the  order  in  which  locking 
protocols  serialise  transactions.  We  use  the  return  order  on  siblings  to  induce  a  partial  order 
"returned)"  on  the  events  of  a.  When  we  reorder  the  events  of  visible{er,T)  to  produce  />,  we  will  use 
the  return  order  so  that  the  transactions  take  steps  in  $  in  an  appropriate  depth-first  order  (ss  they  must 
if  0  is  to  be  a  serial  schedule). 

When  we  are  trying  to  produce  a  serial  schedule  by  reordering  the  operations  of  visible(o,T)1  we  must 
be  careful  not  to  introduce  absurdities,  such  as  moving  a  CREATE  event  before  the  corresponding 

REQUEST _ CREATE.  We  introduce  a  relation  on  the  events  in  a,  "affecUgjo)",  which  records  the 

possible  causal  relation  between  different  events. 

Two  relations  R  and  S  are  contiatent  if  their  union  can  be  extended  to  an  irreflexive  partial  order. 
(That  is,  their  union  has  no  cycles.)  In  this  section  of  the  paper,  we  show  that  returned)  and  afTectSgfa) 
are  consistent  orderings  on  the  events  of  a.  We  use  an  extension  of  the  union  of  these  orders  when 
reordering  visible(o,T)  to  form  0.  We  will  argue  in  the  next  section  of  the  paper  that  if  the  generic 
objects  obey  a  simple  condition  called  dynamic  atomicity,  then  the  reordered  sequence  0  is  a  schedule  of 
the  serial  system.  Later  we  will  show  that  objects  implemented  using  our  Conflict-Based  Locking 
algorithm  or  Moss’  Read/Write  Locking  algorithm  are  dynamic  atomic. 


23 


5.1.  Return  Order 

Let  SIB  be  the  (irreflexive)  sibling  relation  among  transactions,  so  (T,T’)  G  SIR  if  and  only  if  T  ^  T’ 
and  parent(T)=parent(T’).  If  R  C  SIB  is  a  strict  partial  order  (i.e.  a  relation  that  is  transitive, 
irreflexive  and  anti-symmetric)  then  we  call  R  a  sibling  order.  If  a  is  a  sequence  of  events,  then  we  define 
return(a)  to  be  the  binary  relation  on  transactions  containing  (T,T’)  exactly  if  T  and  T’  are  siblings  and 
one  of  the  following  holds. 

•  There  are  return  events  for  both  T  and  T’  in  a,  and  a  return  event  for  T  precedes  a  return 
event  for  T’. 

•  There  is  a  return  event  for  T  in  a,  but  there  is  no  return  event  for  T’  in  a. 

Lemma  21:  Let  a  be  a  generic  schedule.  Then  return(o)  is  a  sibling  order. 

We  will  now  use  the  return  order  on  siblings  to  induce  return  orders  on  transactions,  events  and  deeds. 
The  partial  order  on  events  will  be  the  one  we  use  in  reordering  visible(a,T)  to  give  a  serial  schedule.  If  a 
is  a  sequence  of  events,  we  define  returned)  to  be  the  binary  relation  on  transactions  containing  (T,T’) 
exactly  when  there  exist  siblings  U  and  U’  such  that  T  and  T’  are  descendants  of  U  and  U’,  respectively, 
and  (U,U’)  6  return(a).  We  also  define  returned)  to  be  the  binary  relation  on  the  events  of  a  containing 
(0,»r)  exactly  when  0  and  it  are  distinct  events  of  a  mentioning  transactions  T  and  T’  respectively,  such 
that  (T,T’)  6  returned).  Similarly,  we  define  returnee*)  to  be  the  binary  relation  on  deeds  containing 
((T,t)(T’,t’))  exactly  when  a  contains  events  it  and  <f>  such  that  tt=REQUEST _ COMMIT(T, t) , 
0-—  REQUEST_COMMIT(T’,t’),  and  (it,4>)  G  returned).  Clearly,  each  of  these  derived  relations  is  a 
strict  partial  order. 

Lemma  22:  Let  a  be  a  generic  schedule.  Then  returnT(a)  is  a  strict  partial  order  on 
transactions,  returned)  is  a  strict  partial  order  on  the  set  of  events  of  a,  and  returned)  is  a 
strict  partial  order  on  deeds. 

Lemma  23:  Let  a  be  a  generic  schedule.  Let  it  and  it'  be  events  of  a  mentioning 
transactions  T  and  T’  respectively.  Let  0  and  0’  be  events  of  a  mentioning  transactions  U  and 
U’  respectively,  where  U  is  a  descendant  of  T  and  U’  is  a  descendant  of  T’.  If  (it, it’)  G 
returned)  then  (0,0’)  G  returned). 

5.2.  Affects  Order 

We  now  define  another  partial  order  affectsE(a)  on  the  events  of  a.  This  will  record  those  facts  about 
the  neccessary  order  of  events  that  must  be  enforced  by  the  preconditions  of  the  serial  scheduler.  For  a 
sequence  a  of  events,  and  events  0  and  it  in  o,  we  say  that  0  directly  affects  it  in  a  (and  that  (0,»r)  G 
directly-affectsE(o))  if  at  least  one  of  the  following  is  true. 

•  0  and  it  are  distinct  events  of  the  same  transaction  (including  accesses)and  0  precedes  »r  in  o 

•  0  -=  REQUEST  _CRi  :ATE(T)  and  it  -  CREATE(T) 

•  0  =  REQUEST _COMMlT(T,v)  and  it  =  COMMIT(T) 
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•  <t>  =  REQUEST  _CREATE(T)  and  *  =  ABORT(T) 

•  4  =  COMMIT(T)  and  k  =  REPORT _  COMMIT( T , v ) 

•  4  =  ABORT(T)  and  >r  =  REPORT  _ABORT(T) 

Examining  the  definition  of  the  serial  scheduler,  we  see  that  (4,*)  6  directly-affectsE(o)  either  when  the 
preconditions  of  ic  as  an  operation  of  the  serial  scheduler  include  a  test  for  a  previous  occurrence  of  4,  in 
which  case  a  sequence  of  operations  with  jr  not  preceded  by  4  could  not  possibly  be  a  serial  schedule,  or 
when  ic  and  4  are  operations  of  the  same  transaction,  in  which  case  we  might  ride  introducing  an 
absurdity  if  it  was  not  preceded  by  4>  as  we  assume  very  little  about  the  transaction  automata.  Since  the 
generic  controller  preconditions  also  test  for  the  presence  of  a  preceding  operation  in  each  case  and  do  not 
allow  repeated  instances  of  REQUEST  _  CREATE,  REQUEST  _  COMMIT,  or  return  operations,  it  is 
clear  that  if  a  is  a  generic  schedule,  then  6  directly-affectSgfa)  only  if  4  precedes  ic  in  a. 

For  a  sequence  a  of  events,  define  the  relation  affects^a)  to  be  the  transitive  closure  of  the  relation 
directly- affectsE(a).  If  the  pair  (4,i r)  is  in  the  relation  affects^a),  we  also  say  that  4  affecte  jr  in  a. 

Lemma  24:  Let  a  be  a  generic  schedule.  Then  affects^or)  is  an  irrefiexive  partial  order  on 
the  events  in  a. 

Proofs  We  noted  above  that  4  directly  affects  Jr  in  a  only  if  4  precedes  7r  in  a.  Therefore  4 
affects  k  in  a  only  if  4  precedes  ir  in  a.  Thus  affecteE(a)  is  irrefiexive  and  antisymmetric. 
Since  affectsE(a)  is  constructed  as  a  transitive  closure,  the  result  follows.  □ 

We  now  show  that,  as  claimed  earlier,  the  return  and  affects  orders  are  consistent  partial  orders  on  the 
set  of  events  of  a  generic  schedule.  We  begin  with  two  lemmas. 

Lemma  25:  Let  a  be  a  generic  schedule  such  that  4  directly  affects  tr  in  a,  where  4 
mentions  T  and  w  mentions  T’.  Then  T  —  T’,  T  =  parent(T’)  or  T’  =  parent(T). 

Lemma  25:  Let  a  be  a  generic  schedule.  Let  n  and  it’  be  distinct  events  in  a  mentioning 
transactions  T  and  T’  respectively.  If  T  is  neither  an  ancestor  nor  a  descendant  of  T’,  and 
(jt.jt’)  6  affectSgJor),  then  (ir,ir’)  €  returnE(a). 

Proof:  If  T  is  neither  an  ancestor  nor  a  descendant  of  T’,  there  mu6t  be  siblings  U  and  U’ 
such  that  T  is  a  descendant  of  U,  and  T’  is  a  descendant  of  U\  Let  U”  denote 
parent(U)=parent(U’)=lca(T,T’).  Since  n  affects  ic’  in  a,  there  must  be  a  subsequence 
of  a  such  that  ict=K  and  jrn=»r’,  and  where  each  »r.  directly  affects  «■. 

By  Lemma  25,  by  replacing  each  event  in  <r  with  the  transaction  it  mentions,  a  corresponds 
to  a  path  through  the  transaction  tree,  beginning  at  T  and  ending  at  T’,  where  each  link 
iTjir.+1  is  either  a  self-loop,  goes  from  child  to  parent  or  from  parent  to  child. 

Clearly,  there  must  be  some  step  from  U  to  U”,  and  a  later  step  ir.ir.+1  from  U”  to  U’. 

Examining  the  definition  of  directly  _affectsE,  we  have  that  jr.  is  a  return  for  U,  and  ir.+1  is  a 
report  for  U.  Similarly,  ir.  is  REQUEST ^REATE^’)  and  *\+1  is  either  CREATE(U’)  or 
ABORT(U’).  The  controller  preconditions  and  well-formedness  imply  that  any  return  event 
for  U’  in  a  must  occur  after  the  unique  REQUEST_CREATE(U’)  event.  Thus  a  contains  a 
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return  event  jt.  for  IJ,  and  any  return  event  for  U’  must  be  preceded  by  the  later  event  x.. 
Thus  (U,U’)  €  return(o),  and  therefore  (x.x’)  €  returned).  □ 

Now  we  will  prove  that  the  two  partial  orders  we  have  defined  on  the  events  of  o  are  consistent. 

Lemma  27:  Let  a  be  a  generic  schedule.  Then  returned)  and  affects^ or)  are  consistent 
partial  orders  on  the  events  of  a. 

Proof:  We  prove  this  lemma  by  contradiction.  If  returnee*)  and  affects£(a)  are  not 

consistent,  then  there  is  a  cycle  in  the  relation  returned)  U  affectSgfd),  and  thus  there  must 

be  some  shortest  cycle.  Let  x_,  x.,  itn,  ...,  it  ,,  it  = x„  be  such  a  shortest  cycle,  where  for  each 

u  i  i  o*  I  n  u 

i,  (x.,x.  )  6  returned)  U  affectSg(d).  In  the  following  discussion  we  will  use  arithmetic 

modulo  n  for  subscripts,  so  that  if  i=0,  jt_j  is  to  be  interpreted  as  ir^  j.  We  note  that  n>l, 
since  both  returned)  and  affectSg(o)  are  irreflexive. 

Since  the  relation  returned)  is  acyclic,  there  must  be  at  least  one  index  i  such  that  (x.,x.+1) 
€  affectsgjd).  Let  T  and  T’  be  the  transactions  mentioned  by  x.  and  x+1  respectively.  We 
divide  the  discussion  into  three  cases,  depending  on  the  relationship  between  T  and  T’  in  the 
transaction  tree. 

If  T  is  an  ancestor  of  T’,  then  consider  the  pair  (x.^,x.).  If  this  pair  is  in  affects^d),  then  by 
the  transitivity  of  the  affects  relation,  (x-^x.+j)  €  affects^o).  However  if  (jT  j.jt)  € 
returned),  then  by  Lemma  23  (x.^,x.+1)  6  returned).  In  either  situation,  we  can  find  a 
shorter  cycle  in  the  relation  returned)  u  affected),  by  omitting  x.  This  contradicts  our 
assumption,  since  the  cycle  chosen  was  as  short  as  possible. 

If  T  is  a  descendant  of  T’,  we  consider  the  pair  (x.+1,x.+2).  If  this  pair  is  in  affects^a),  then 
by  the  transitivity  of  the  affects  relation,  (x.,x.+2)  6  affectSg(o).  However  if  (xj+1,x.+2)  € 
returned),  then  by  Lemma  23  (x.,x.+2)  €  returned).  In  either  situation,  we  can  find  a  shorter 
cycle  in  the  relation  returned)  U  affects^d),  by  omitting  xj+1.  This  contradicts  our 
assumption,  since  the  cycle  chosen  was  as  short  as  possible. 

Finally,  if  T  is  neither  an  ancestor  nor  a  descendant  of  T’,  then  by  Lemma  26,  (x.,x.+1)  is  in 
returned)  as  well  as  in  affectsE(d).  Now  consider  the  pair  (x.^,x.).  If  this  pair  is  in  affects^o), 
then  by  the  transitivity  of  the  affects  relation,  (xM,x.+1)  €  affectSg(o).  However  if  (r^ir.)  e 
returned),  then  by  the  transitivity  of  the  return  relation  €  returned).  In  either 

situation,  we  can  find  a  shorter  cycle  in  the  relation  returned)  U  affectSgfd),  by  omitting  x.. 
This  contradicts  our  assumption,  since  the  cycle  chosen  was  as  short  as  possible. 

In  every  case  we  have  found  a  contradiction,  thus  the  assumption  that  the  relation 
returned)  U  affects^ a)  contains  a  cycle  must  be  wrong.  □ 
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6.3.  Visibility 

Recall  that  visible(a,T)  is  the  subsequence  of  a  consisting  of  the  events  n  such  that  transaetioii(jr)  is 
visible  to  T.  We  begin  our  study  of  the  way  the  return  and  affects  orders  relate  the  events  of  visible(«,T), 
in  preparation  for  the  main  correctness  proof  of  the  next  section. 


First  we  show  that  two  transactions  mentioned  in  such  a  subsequence  must  be  ordered  by  the  return 
order,  unless  one  is  an  ancestor  of  the  other,  and  that  therefore  the  return  order  determines  the  relative 

order  of  many  of  the  events  in  the  subsequence. 

Lemma  28:  Let  a  be  a  generic  schedule,  and  T”  any  transaction.  Let  it  and  n'  be  events  in 
visible(ar,T”)  such  that  there  are  transactions  T  and  T’  where  it  mentions  T,  it'  mentions  T\ 
and  T  is  neither  an  ancestor  nor  a  descendant  of  T’.  Then  either  (tt.jt’)  6  returnE(a),  or  (ir’,ir) 

6  returnE(a). 

Proof:  Let  U  and  U’  be  distinct  sibling  transactions  such  that  T  is  a  descendant  of  U,  and  T’ 
is  a  descendant  of  U’.  Since  U  and  U’  are  distinct  siblings,  T”  is  not  a  descendant  of  both  U 
and  U’.  Without  loss  of  generality,  we  will  assume  that  T”  is  not  a  descendant  of  U.  Note  that 
therefore  the  least  common  ancestor  of  T”  and  a  descendant  of  U  must  be  an  ancestor  of 
parent(U).  Since  it  mentions  T,  transaction^)  must  be  T  or  parent(T).  Thus  transaction^)  is 
a  descendant  of  U  unless  it  is  a  return  event  for  U  itself.  Since  it  is  visible  to  T”  in  a,  a  must 
contain  a  COMMIT  event  for  every  transaction  that  is  an  ancestor  of  transaction(jr)  and  a 
strict  descendant  of  lca(transaction(ff),T”)-  If  transaction^)  is  a  descendant  of  U,  then  a  must 
therefore  contain  a  COMMIT(U)  event.  If  transaction^)  is  not  a  descendant  of  U,  then  we 
saw  that  it  itaelf  must  be  a  return  event  for  U.  In  either  case  a  contains  a  return  event  for  U, 
and  so  return(a)  orders  U  and  U\  Therefore  returned)  orders  T  and  T\  An  immediate 
consequence  is  that  return^a)  orders  it  and  it'.  □ 

Lemma  29:  Let  a  be  a  generic  schedule,  let  T  be  any  transaction  and  X  any  object.  Then 
there  is  a  unique  reordering  of  visible(a,T)jX  consistent  with  returned)  U  affectsgfa). 

Proof:  By  Lemma  27  the  partial  orders  returnE(a)  and  affectSg(a)  are  consistent.  This 
implies  the  existence  of  a  reordering  of  visible(or,T)|X  consistent  with  both.  Uniqueness  of  the 
reordering  will  be  proved  otoce  we  show  that  any  two  events  of  visible(a,T)|X  are  ordered  by 
one  of  the  partial  orders.  Thus,  let  it  and  it'  be  distinct  events  of  visible(a,T)|X.  Let  U  and 
U\  respectively,  be  the  accesses  of  which  it  and  it'  are  operations.  If  U=U’,  then  it  and  it'  are 
ordered  by  affects^a).  If  U  ^  U’,  then,  since  U  and  U’  are  accesses,  U  is  neither  an  ancestor 
nor  a  descendant  of  U’.  By  Lemma  28,  returned)  orders  it  and  it’.  □ 

For  a  a  generic  schedule,  T  a  transaction  and  X  an  object,  define  serialize(a,T,X)  to  be  the  unique 
sequence  that  is  a  reordering  of  visible(o,T)|X  consistent  with  returned)  U  affectsE(o),  which  exists  by 
Lemma  29. 


A  useful  observation  is  the  following: 

Lemma  30:  Let  a  be  a  generic  schedule,  T  a  transaction  that  is  not  an  orphan  in  a,  and  X 
an  object.  The  sequence  serialize(o,T,X)  is  well-formed  as  a  sequence  of  operations  of  basic 
object  X. 

Proof:  Suppose  ir  is  an  event  of  serialise(a,TX)'  There  are  two  cases  to  consider:  either  it  is 
CREATE(U)  or  it  is  REQUEST_COMMIT(U,u) 
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If  it  is  CREATE(U),  then  since  a|X  is  a  well-formed  schedule  of  generic  object  X,  a  contains 
only  one  CREATE(U)  event.  Thus  serialize! or  ,T,X)  contains  no  CREATE(U)  event  other  than 
it.  We  also  need  to  prove  that  no  access  to  X  is  pending  in  the  prefix  of  serialize^, T,X) 
preceding  it.  Thus  suppose  that  U’  is  an  access  to  X  such  that  CREATE(U’)  precedes  it  in 
serialize^, T,X).  Then  U’  jL  U,  and  since  visible(or,T)  contains  both  CREATE(U’)  and  it,  by 
Lemma  28  we  deduce  that  (CREATE(U’),Jr)  €  returnE(o).  Therefore  (U’,U)  6  returnT(o). 
Thus  a  contains  a  return  event  for  some  ancestor  of  U’,  and  since  CREATE(U’)  is  visible  to  T 
in  a,  U’  is  not  an  orphan  in  a.  Thus  by  Lemma  20  a  contains  a  COMMIT(U’)  event,  and 
therefore  also  a  REQUEST _COMMTr(U\u’)  event  for  some  value  u\  Since  (U’,U)  € 
returnT(or),  we  deduce  that  (REQUEST  _COMMIT(U’,u’),jr)  6  returnee*),  so  that 
REQUEST _COMMIT(U’,u’)  precedes  it  in  serialize(o,T,X).  Thus  U’  is  not  pending  in  the 
prefix  of  serialize^, T,X)  preceding  it. 

If  jt  is  REQUEST  _COMMIT(U)u),  then  since  a[X  is  a  well-formed  schedule  of  generic  object 
X,  a  contains  CREATE(U)  preceding  it,  and  a  contains  no  REQUEST _  COMMIT  event  for  U 
other  than  it.  Thus  (CREATE(U),ir)  6  affects^a)  and  since  CREATE(U)  is  in  visible(o,T), 
CREATE(U)  precedes  it  in  serialize(o,T,X).  Also  serialize^, T,X)  does  not  contain  a 
REQUEST  _  COMMIT  event  for  U  other  than  it.  □ 


6.  Proving  Serial  Correctness 


S.l.  The  Serial  Correctness  Theorem 

The  following  lemma  establishes  conditions  on  generic  objects  that  are  sufficient  to  ensure  the 
correctness  of  generic  systems;  i.e.  that  non-orphans  see  serial  schedules.  Actually,  the  statement  and 
proof  of  the  lemma  establishes  a  stronger  property:  from  any  serial  schedule  or  and  non-orphan 
transaction  T,  we  explicitly  construct  a  serial  schedule  0  that  is  transaction  equivalent  to  visible(a,T),  i.e. 
d|T’=visible(«,T)|T’  for  all  transactions  T'.  Note  that  if  T’  is  visible  to  T  in  a,  then  by  Lemma  13 
visible(a,T)(T’  =  a|T’.  Thus,  the  single  serial  schedule  /3  is  a  serial  schedule  that  is  consistent  with  the 
local  schedules  of  every  transaction  visible  to  T. 

Lemma  31:  Let  a  be  a  generic  schedule,  and  let  T  be  any  transaction  that  is  not  an  orphan 
in  a.  Suppose  that  for  each  object  X,  serialize(o,T,X)  is  a  schedule  of  basic  object  X.  Then 
there  is  a  serial  schedule  0  such  that  0  and  visible(o,T)  are  transaction-equivalent. 

Proof:  Note  first  that  by  Lemma  29,  serialize^, T,X)  is  well  defined. 

By  Lemma  27,  affect s^ar)  U  return(ar)E  is  an  acyclic  relation  on  the  events  of  a,  and  hence 
on  the  events  of  visible(a,T).  Then  there  exist  total  orderings  on  the  events  of  visible(o,T) 
that  extend  affectsE(a)  U  return(a)E>  Let  0  be  a  sequence  obtained  by  reordering  visible(a,T) 
by  such  a  total  ordering.  We  argue  that  0  and  visible(o,T)  are  transaction-equivalent,  and 
that  0  is  a  serial  schedule. 

First  we  note  that  since  0  is  a  rearrangement  of  visible(a,T),  the  events  in  0\T’  are  the  same 
as  the  events  in  visible(ar,T)|T’,  for  any  T’.  Suppose  it  and  <t>  are  two  events  of  visible(o,T)|T’, 
and  it  precedes  <f>  in  visible(o,T).  Then  (it,4>)  €  directly-affectsE(a),  and  so  it  must  precede  <t>  in 
0,  since  the  order  of  events  in  0  is  consistent  with  affects^a).  This  shows  that 
/J)T’=visible(a,T)|T\  Thus  0  is  transaction-equivalent  to  visible(or,T). 


Now  we  argue  that  0  is  a  serial  schedule.  The  proof  is  by  induction  on  prefixes  of  0,  with  a 
trivial  basis.  Let  0'w  be  a  prefix  of  0  with  w  a  single  event,  assume  that  0'  is  serial,  and  let  s’ 
be  the  state  of  the  serial  scheduler  after  0\  There  are  six  cases. 

1)  it  is  an  output  of  a  non-access  transaction  T’. 

Then  T’  must  be  visible  to  T  in  a,  and  so  by  Lemma  13  visible(a,T)|T’=a[T’.  We  saw  above 
that  0  and  visible(a,T)  are  transaction  equivalent,  so  we  may  deduce  that  $|T’=a|T’.  Thus 
0'n\T'  (which  is  a  prefix  of  0|T’)  is  a  prefix  of  a|T’,  which  is  a  schedule  of  T\  Thus  ^’a-fT’  is 
a  schedule  of  T’.  Hie  result  follows  by  Lemma  1. 

2)  ir  is  an  output  of  an  access  transaction  T’. 

Let  T’  be  an  access  to  the  object  X.  By  assumption,  serialize^, T,X)  is  a  schedule  of  basic 
object  X,  and  by  construction,  0|X  =  serialize^, T,X).  Since  /9’wjX  is  a  prefix  of  0|X,  /}’ir|X  is 
a  schedule  of  basic  object  X.  The  result  follows  by  Lemma  1. 

3)  it  is  CREATE(T’) 

We  must  show  that  w  is  enabled  as  an  operation  of  the  serial  scheduler  in  state  s’.  That  is,  we 
must  show  that  T’  €  s’.create_ requested  -  (s’. created  U  s’. aborted)  and  that  siblings^’)  O 
s’.created  C  s’.returned. 

By  the  preconditions  of  the  generic  controller  and  Lemma  16,  a  REQUEST_CREATE(T’) 
event  precedes  and  affects  ir  in  a.  Since  transaction(ir)=T’,  T’  must  be  visible  to  T  in  a,  and 
therefore  parent(T’)  is  also  visible  to  T  in  a.  Since 
transac  tion(HEQUEST  _  CREATE(T’))=  parent(  T’) ,  the  event  REQUEST  _CREATE(T’) 
occurs  in  visible(a,T)  and  thus  in  0.  Since  the  order  of  events  in  0  is  consistent  with 
affects^fa),  the  REQUEST _CREATE(T’)  event  must  precede  ir  in  0,  so  by  Lemma  4,  T’  € 
s’. create _ requested.  Since  only  one  CREATE  for  T’  occurs  in  a,  no  CREATE(T’)  occurs  in 
0\  so  by  Lemma  4,  T’  f  s’.created.  Since  by  Lemma  19,  T’  is  not  an  orphan  in  o,  no 
ABORT(T’)  occurs  in  a.  Thus  no  ABORT(T’)  occurs  in  0',  so  by  Lemma  4  T'  )f  s’. aborted. 
This  completes  the  demonstration  that  T’  €  s’.create_ requested  -  (s’.created  U  s’.aborted). 

Now  suppose  T”  is  a  sibling  of  T’  that  is  in  s’.created.  Then  CREATE(T”)  occurs  in  0\ 
Since  the  order  of  events  in  0  is  consistent  with  returned),  and  CREATE(T”)  precedes 
CREATE(T’)  in  0,  we  cannot  have  (T’,T”)  €  returnT(a).  Thus  by  Lemma  28,  returnee*) 
contains  (T”,T’).  Thus  a  contains  a  return  event  %!>  for  T”.  Now 

transaction(V')=parent(T”)=parent(T’)  is  visible  to  T  in  or,  so  0  occurs  in  0.  Since  is  an 
event  that  mentions  T”,  we  have  €  returned),  and  so  V  precedes  ir  in  0.  Thus  a  return 
event  for  T”  occurs  in  0\  proving  that  T”  €  s’.returned. 

4)  ir  is  COMMIT(T’) 

We  must  show  that  (T’,v)  6  s’.commit_  requested  for  some  v,  and  that  T’  £  s’.returned. 

By  the  preconditions  of  the  generic  controller  and  Lemma  16,  there  is  a  value  v  so  that  a 

REQUEST _ COMMIT(T’.v)  precedes  and  affects  ir  in  a.  Since  jr  occurs  in  0, 

transaction(jr)=parent(T’)  must  be  visible  to  T  in  a.  However  since  COMMIT(T’)  occurs  in  a, 
T’  is  visible  to  parent(T’)  in  a,  and  so  by  Lemma  9,  T’  is  visible  to  T  in  a.  Thus 
REQUEST _COMMlT(T’,v)  occurs  in  visible(a,T),  and  thus  it  occurs  in  0.  Since  the  order  of 
events  in  0  is  consistent  with  affects^cr),  the  REQUEST_COMVflT(T’,v)  event  must  occur  in 
0’.  Thus  (T’,v)  6  §’.commit_requestod. 


29 


The  other  condition,  T’  £  s’. returned,  is  true  because  (by  Lemma  17)  there  is  only  one  return 
for  jr  in  a  and  hence  only  one  in  0. 

i)  it  is  ABORT(T’) 

We  must  show  that  T’  €  s’.create_ requested  -  (s’. created  U  s’. aborted)  and  siblings(T’)  fl 
s’.created  C  s’returned. 

By  the  preconditions  for  the  generic  controller  and  Lemma  16,  a  REQUEST_CREATE(T,) 
event  precedes  it  and  affects  ir  in  a.  Since  transaction(REQUEST_CREATE(T’))  = 
parent(T’)  =  transaction^),  the  REQUEST _CREATE(T’)  event  occurs  in  visible(a,T)  and 
hence  in  0.  Since  the  order  of  events  in  0  is  consistent  with  affectsE(o),  the 
REQUEST_CREATE(T’)  occurs  in  0\  so  that  T’  €  s’. create _  requested.  Also  T’  is  an  orphan 
in  a,  so  by  Lemma  19,  T’  is  not  visible  to  T  in  o.  Thus  CREATE(T’)  does  not  occur  in 
visible(a,T),  and  so  also  CREATE(T’)  does  not  occur  in  0.  Thus  T’  £  s’.created.  Since  by 
Lemma  17  there  is  at  most  one  ABORT(T’)  in  a,  there  can  be  no  ABORT(T’)  event  in  0'. 
Thus  by  Lemma  4  T’  £  s’. aborted. 

Suppose  T”  is  a  sibling  of  T’  such  that  T”  6  s’.created.  By  Lemma  4,  a  CREATE(T”)  event 
occurs  in  0’  preceding  it.  Since  the  order  of  events  in  0  is  consistent  with  returnE(a),  and 
CUEATE(T”)  precedes  ABORT(T’)  in  0,  we  cannot  have  (T’,T”)  €  returnT(a).  Thus  by 
Lemma  28,  returnT(a)  contains  (T”,T’).  Thus  a  contains  a  return  event  ip  for  T”.  Now 
transaction(V')=parent(T”)— parent(T’)  is  visible  to  T  in  or,  so  V’  occurs  in  0.  Since  ip  is  an 
event  that  mentions  T”,  we  have  (V>,jt)  €  retumE(o),  and  so  ip  precedes  k  in  0.  Thus,  T”  € 
s’. returned,  as  required. 

6)  it  is  a  REPORT  _  ABORT  or  REPORT  _  COMMIT  event  for  T’ 

By  the  preconditions  of  the  generic  controller  and  Lemma  16,  n  is  preceded  and  affected  by  the 
appropriate  return  event  ip  in  a.  Since  transaction(^)*=parent(T’)=transaction(ir),  ip  must 
occur  in  visible(a,T)  and  hence  in  0.  Since  the  order  of  events  in  0  is  consistent  with 
affectsE(a),  ip  must  occur  in  0\  and  so  jr  is  enabled  as  an  operation  of  the  serial  scheduler  after 
0\  □ 

The  previous  lemma  enables  us  to  deduce  that  a  generic  schedule  a  is  serially  correct  for  a  non-orphan 
transaction  T  if  every  object  satisfies  a  simple  condition  that  depends  on  o  and  T. 

Theorem  32:  Let  a  be  a  generic  schedule,  and  let  T  be  any  transaction  that  is  not  an 
orphan  in  a.  Suppose  that  for  each  object  X,  serialiie(a,T,X)  is  a  schedule  of  basic  object 
X.  Then  there  is  a  serial  schedule  0  such  that  a|T=/9|T. 


6.2.  Dynamic  Atomicity 

In  any  practical  system,  we  would  hope  that  all  generic  schedules  would  be  serially  correct  for  all  non¬ 
orphan  transactions.  Let  X  be  a  generic  object  in  generic  system  S.  We  say  that  X  is  dynamic  atomic  in 
S  if  for  every  schedule  a  of  S,  and  every  transaction  T  that  is  not  an  orphan  in  o,  serialite(a,T,X)  is  a 
schedule  of  basic  object  X.  A  generic  system  S  is  a  dynamic  atomic  syttem  if  every  generic  object  is 
dynamic  atomic  in  S. 

We  thus  have  the  following  consequence  of  Theorem  32: 
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CoroUwy  Ui  Dynutic  atonic  systems  are  aerially  correct  for  every  non-orphan 
transaction. 

The  Conflict-Based  Locking  objects  we  will  construct  in  this  paper,  and  the  R/W  Locking  objects  that 
represent  data  items  implemented  using  Moss’  algorithm,  have  an  even  stronger  property,  because  they 
ensure  serial  correctness  no  matter  what  choices  are  made  of  transaction  automata  to  be  used  i»  the 
system.  We  say  a  generic  object  X  is  dynamic  atomic  if  it  is  dynamic  atomic  in  every  generic  system  (of 
the  fixed  system  type)  that  contains  X. 

Corollary  34:  Let  5  be  a  generic  system  such  that  every  generic  object  is  dynamic  atomic. 
Then  S  is  serially  correct  fbr  every  non-orphan  transaction. 

Thus  dynamic  atomic  object*  respond  to  accesses  in  such  a  way  that  the  resulting  schedules  can  be 
serialized  in  return  order.  In  fact,  the  return  order  is  not  known  to  the  objects,  as  it  is  determined 
dynamically  by  the  controller,  so  that  a  dynamic  atomic  object  must  ensure  that  its  responses  to  accesses 
can  be  serialized  in  every  sibling  order  which  could  be  the  return  order,  based  on  the  local  history  of  the 
object,  but  given  no  information  about  the  other  components  of  the  system. 

0.3.  Local  Information 

The  previous  section  showed  that  to  prove  a  system  serially  correct  for  non-orphan  transactions  it  is 
enough  to  check  that  each  generic  object  is  dynamic  atomic.  For  each  generic  object  X,  this  is  a  local 
condition  because  it  depends  only  on  X,  but  to  check  it  one  must  compute  serialize(o,T,X)  for  all 
schedules  a  of  alt  generic  systems  containing  X.  In  this  section  we  introduce  a  property  that  is  sufficient 
to  prove  dynamic  atomicity,  but  that  i»  easily  checked  merely  by  examining  the  schedules  of  X. 

First  we  introduce  some  terms  that  enable  us  to  describe  information  about  the  fate  of  transactions,  and 
about  return  order,  that  is  available  to  a  generic  object  given  its  local  history.  Let  a  be  a  sequence  of 
operations  of  generic  object  X,  T  a  transaction,  and  T’  an  ancestor  of  T.  We  say  that  T  is  com  nutted  at 
X  to  T’  in  a  if  a  contains  an  INFORM  _  COMMIT  _ AT(X)OF(U)  for  every  U  that  is  an  ancestor  of  T 
and  a  proper  descendant  of  T’.  If  o  is  a  sequence  of  operations  of  X  and  T  and  T’  are  any  transactions, 
we  say  that  T  is  tactile  at  XtoT’inaifTis  committed  at  X  in  a  to  l«a(T,T’).  We  denote  by 
visible-at-X(a,T)  the  subsequence  of  a  consisting  of  events  w  such  that  transaction^)  is  visible  at  X  to  T 
in  a.  We  say  that  T  is  an  orphan  at  X  in  or  if  lNFORM_ABORT_AT(X)OF(U)  occurs  in  a  for  some  U 
which  is  an  ancestor  of  T. 

We  collect  here  some  obvious  facts  about  visibility  at  X  of  transactions. 

Lemma  S3:  Let  a  be  a  sequence  of  operations  of  X  and  0  a  subsequence  r>r  n.  Let  T  be  an 
access  to  X  and  T’  a  transaction.  If  T  is  visible  at  X  to  T’  in  0  then  T  is  visible  at  X  to  T’  in 

a. 

Lemma  36:  Lei  a  be  a  sequence  of  operations  of  X,  and  let  T,  T’  and  T”  be  transactions.  If 
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T  is  visible  at  X  to  T’  in  o,  and  T’  is  visible  at  X  to  T”  in  a,  then  T  is  visible  at  X  to  T”  in 
a. 

Lemma  37s  Let  a  be  a  well-formed  sequence  of  operations  of  X,  and  let  T  and  T’  be 
transactions.  If  T  is  visible  at  X  to  T’  in  o,  and  T’  is  not  an  orphan  at  X  in  a,  then  T  is  not 
an  orphan  at  X  in  o. 

We  will  next  define  a  relation  on  accesses  to  the  generic  object  X,  which  reflects  some  information  that 
X  can  deduce  about  the  return  order,  given  its  local  knowledge  of  the  schedule.  Given  a  sequence  a  of 
operations  of  generic  object  X,  we  define  a  binary  relation  return- at-Xq.( a)  on  accesses  to  X,  where  (U,U) 

€  return-at-Xp(o)  exactly  when  U  U’,  a  contains  both  REQUEST _ COMMIT(U,v)  and 

REQUEST_COMMIT(U’,v’)  for  some  values  v  and  v’,  and  U  is  visible  at  X  to  U'  in  o’,  where  o’  is  the 
longest  prefix  of  o  not  containing  REQUEST_COMMIT(U’,v’).  The  intuition  on  which  this  definition  is 

based,  is  that  the  COMMIT  operation  of  any  ancestor  of  U  must  precede  an  INFORM _ COMMIT  for 

that  transaction,  but  the  COMMIT  for  an  ancestor  of  U’  must  follow  the  REQUEST _ COMMIT  for  U’, 

so  long  as  U’  is  not  an  orphan.  Thus  if  neither  U  nor  U’  are  orphans,  and  an  INFORM _ COMMIT  for 

the  ancestor  of  U  that  is  a  child  of  !ca(U,U’)  precedes  the  REQUEST  _  COMMIT  for  U’,  then  U  must  be 
ordered  before  U’  in  the  return  order.  The  possibility  of  orphans  leads  to  the  complicated  definition  given. 

We  will  also  consider  the  induced  relations  return-at-XE(a)  on  the  events  of  a,  and  return-at-X^o)  on 
deeds  at  X.  The  first  is  defined  by  the  condition  that  (d,*)  €  return-at-X^o)  if  and  only  if  <t>  and  it  are 
events  of  o  mentioning  accesses  U  and  U’  respectively,  and  (U,U’)  €  return-at-X^o).  Similarly,  we  define 
the  second  by  ((U,v),(U’,v’))  6  return-at-Xp(a)  if  and  only  if  €  return- at^XE(o),  where 

d— REQUEST _ COMMIT( U,v)  and  jr=REQUEST_COMMIT(U’,v’). 

We  now  show  that  when  a  is  a  well-formed  sequence  of  operations  of  generic  object  X,  return-at-XT(a) 
is  a  partial  order  on  accesses  lo  X.  An  immediate  consequence  of  this  is  that  the  derived  relations  on 
events  and  deeds  are  also  partial  orders. 

Lemma  88:  If  a  is  a  well-formed  sequence  of  operations  of  generic  object  X  then 
return-at-Xj.(a)  is  a  partial  order  on  accesses  to  X. 

Proof:  First,  we  note  that  by  definition  return-at-X^o)  is  irrefiexive.  Now,  since  or  is  well- 
formed,  if  T  y*  T’  and  T  is  visible  at  X  to  T’  in  a’  then  o’  contains  a  REQUEST _  COMMIT 
operation  for  T.  Thus  the  definition  shows  that  (T,T’)  €  return-at-Xj.(o)  only  if 
REQUEST  _COMMIT(T,v)  precedes  REQUEST  _COMMIT(T’,v’)  in  o.  Since  o  is  well- 
formed,  it  contains  at  most  one  REQUEST  _  COMMIT  operation  for  each  access,  and  therefore 
return- at- X^o)  is  antisymmetric.  Finally,  suppose  (T,T’)  €  return-at-XT(o)  and  (T’,T”)  € 
return-at-XT(o).  Let  o’  denote  the  longest  prefix  of  o  not  containing 

REQUEST _COMMIT(T’,v’)  and  let  o”  denote  the  longest  prefix  of  o  not  containing 
REQUEST  I  COMMIT(T”,v”).  We  have  seen  that  REQUEST_COMMIT(T’,v’)  precedes 
REQUEST  _COMMlT(T”,v”)  in  o,  so  o’  is  a  prefix  of  a”.  Since  T  is  visible  at  X  to  T'  in  o’, 

T  is  visible  to  T’  at  X  in  o”,  and  since  T’  is  visible  to  T”  at  X  in  n”,  we  may  apply  Lemma 
M  to  deduce  that  T  is  visible  to  T”  at  X  in  a”.  Thus  (T,T”)  €  return-at-X^.(o).  □ 

Lamm  a  38:  If  o  is  a  well-formed  sequence  of  operations  of  generic  object  X  then 
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return-at-Xg(a)  is  a  partial  order  on  the  events  of  a,  and  return^st-X^a)  is  a  partial  order  on 
deeds  at  X. 


We  say  that  generic  object  X  is  local-dynamic  atomic  if  whenever  a  is  a  well-formed  schedule  of  X,  7  is 
a  sequence  of  input  operations  such  that  07  is  well-formed,  T  is  a  transaction  that  is  not  an  orphan  at  X 
in  a 7,  and  0  is  a  reordering  of  visible- at-X(o7,T)  that  is  consistent  with  return-at-Xg(a),  and  that  is  a 
well-formed  sequence  of  operations  of  basic  object  X,  then  0  is  a  schedule  of  basic  object  X.  We  note  that 
return-at-XE(a)  is  equal  to  return-at-X^oq).  The  intuition  behind  the  definition  is  that  a  may  not 
contain  enough  information  about  the  fates  of  transactions  to  determine  which  accesses  are  visihle  to  T, 
so  we  need  to  consider  any  sequence  7  of  input  operations  that  can  bring  more  information.  Then  the 
sequences  0  described  will  include  all  sequences  that  are  consistent  with  the  global  return  order,  and  so 
should  be  considered  when  proving  dynamic  atomicity. 


We  now  justify  the  names  introduced  above  by  showing  the  relationship  between  each  local  property 
defined  above  and  the  corresponding  global  property. 

Lemma  40:  Let  a  be  a  schedule  of  a  generic  system  containing  generic  object  X.  If 
transaction  U  is  an  orphan  at  X  in  a|X  then  U  is  an  orphan  in  a.  Similarly  if;  U  is  committed 
at  X  to  V  in  ar{X  then  U  is  committed  to  V  in  a.  Also  if  U  is  visible  at  X  to  V  in  a|X  then  U 
is  visible  to  V  in  or. 

Proof:  These  are  immediate  consequences  of  the  controller  preconditions,  which  imply  that 
any  INFORM  _  ABORT  _AT(X)OF(fE)  in  a  must  be  preceded  by  an  ARORT(T),  and'  that  any 
INFORM_  COMMIT  _AT(X)OF(U)  is  preceded  by  COMMIT(U). 

Next,  we  show  that  for  non-orphan  transactions,  return-at-XT(o|X)  is  a  subrelation  of  return^a). 

Lemma  41:  Let  cr  be  a  schedule  of  a  generic  system  containing  generic  object  X.  If  (T,T*)  € 
return-at-XT(o|X),  and  T’  is  not  an  orphan  in  a,  then  (T,T’)  6  returnT(a). 

Proof:  By  definition  of  the  relation  return-at-XT(  a  |X),  a|X  coatatns  a 
REQUEST _COMMJTfT’,v’)  event  for  some  value  v’.  Letting  a’  denote  the  longest  prefix  of  a 
not  containing  REQUEST  __  COMMJT(T’,v’),  the  definition  also  enables  us  to  say  that  T  is 
visible  at  X  to  T’ m  or’|X.  %  Lemma  40,  this  implies  that  T  is  visible  to  T’  in  o’.  Let  U  aad 
U’  denote  the  siblings  such  that  T  is  a  descendant  of  U,  and  T’  is  a  descendant  of  U’.  Thua  a’ 
contains  a  COMMIT(U)  event.  However  since  a  is  well-formed,  it  contains  at  most  one 
REQUEST  _  COMMIT  event  for  T\  and  so  a’  does  not  contain  a  RE  QUEST  _  COMMIT 
event  for  T’.  By  the  controller  preconditions,  o’  does  not  contain  a  COMMIT(T’)  event.  Since 
a  is  well-formed,  o’  does  contain  a  CREATE(T’)  event.  Since  T’  is  not  an  orphan  in  a,  o’  does 
not  contain  an  ABORT(T’)  event.  Thus  T’  is  live  in  o’.  By  Lemma  20,  U’  must  be  live  in  o’. 
Since  a’  contains  a  return  for  U,  and  no  return  for  U’,  we  have  that  (U,UT  €  returnlo) 
Therefore  (T,T’)  €  returnlo).  □ 

Of  course  it  follows  immediately  that  if  (»,*’)  €  return-at-XE(a|X)  and  it  does  not  mention  a  transaction 
which  is  an  orphan  in  a,  then  (*,»’)  €  return-at-Xg(o|X). 


Finally  we  show  that  local  dynamic  atomicity  is  a  sufficient  condition  for  dynamic  atomicity. 

Lemma  4S:  If  X  is  a  generic  object  that  is  local-dynamic  atomic  then  X  is  dynamic  atomic. 
Proof:  Let  S  be  a  generic  system  containing  X  as  generic  object.  Let  a  be  a  schedule  of  S, 
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and  T  a  transaction  that  is  not  an  orphan  in  a.  We  must  prove  that  serialize(o,T,X)  is  a 
schedule  of  basic  object  X.  Let  7  denote  a  sequence  of  operations  consisting  of  an 
INFORM _ COMMIT  _AT(X)OF(U)  for  each  COMMIT(U)  that  occurs  in  a.  Then  07  is  a 
schedule  of  the  system  S,  since  each  operation  in  7  is  an  output  of  the  generic  controller  which 
is  enabled  by  Lemma  16.  Thus  a7|X  is  well-formed.  We  note  that  since 
INFORM _ COMMIT _AT(X)OF(U)  occurs  in  e»7|X  if  and  only  if  COMMIT(U)  occurs  in  or, 
visible-at-X(a7|X,T)  =  visible(o,T)j\.  Thus  serialize^, X,T),  which  is  a  reordering  of 
visible(o,T)  consistent  with  returnin'),  is  a  reordering  of  visible-at-X((o|X)(7)X),T)  consistent 
with  return-at-XE(a|X).  Furthermore  serialize(a,T,X)  is  a  well-formed  sequence  of  operations 
of  basic  object  X.  Because  X  is  local-dynamic  atomic,  any  such  reordering  must  be  a  schedule 
of  basic  object  X.  This  completes  the  proof  that  X  is  dynamic  atomic.  □ 


7.  Semantic  Conditions 

We  will  give  an  algorithm  that  performs  concurrency  control  and  recovery  using  information  about 
which  locks  may  not  be  held  simultaneously  by  different  transactions.  In  order  for  the  algorithm  to  work 
correctly,  this  information  about  lock  "conflicts*  must  accurately  reflect  the  behavior  of  the  basic  object 
involved.  That  is,  we  require  operations  whose  locks  do  not  conflict  to  have  the  same  effect,  regardless  of 
the  order  in  which  they  occur.  To  describe  this  requirement,  and  to  reason  about  the  resulting  generic 
object,  we  need  to  introduce  some  terms  to  express  facts  about  the  semantics  of  operations.  First,  we 
define  the  fundamental  concept  of  “equieffectiveness*  of  schedules  to  capture  precisely  the  idea  of  two 
schedules  with  the  same  effects.  We  can  then  define  "commutativity".  For  our  discussion  of  Read/Write 
Locking  we  also  need  to  define  "transparency*  of  operations;  an  operation  is  said  to  be  transparent  if 
later  accesses  to  the  same  object  return  values  that  are  the  same  as  in  the  situation  where  the  operation 
did  not  occur. 

7.1.  Equieffeetive  Schedules 

We  introduce  the  concept  of  equieffeetive  schedules  of  a  basic  object  X  in  order  to  define  precisely  what 
schedules  we  will  regard  as  "essentially"  the  same.  Intuitively,  these  are  schedules  that  leave  the 
automaton  in  states  that  are  the  same.  However,  we  are  really  interested  in  observable  behavior,  not 
states,  so  it  is  enough  that  they  be  indistinguishable  by  later  operations.  Formally,  given  two  well-formed 
sequences  a  and  0  of  operations  of  X,  we  say  that  a  is  equieffeetive11  to  0  if  for  every  sequence  <f>  of 
operations  of  X  such  that  both  a<t>  and  0<f>  are  well-formed,  a<f>  is  a  schedule  of  X  if  and  only  if  0<f>  is  a 
schedule  of  X.  Notice  that  if  neither  a  nor  0  is  a  schedule  of  X,  then  o  is  trivially  equieffeetive  to  0. 
Also,  notice  that  if  a  is  equieffeetive  to  0  and  0  is  a  schedule  of  X,  then  a  is  a  schedule  of  X.  In  the  sense 
of  semantic  theory,  equieffeetive  schedules  pass  the  same  tests,  where  a  test  involves  determining  if  a 
given  sequence  of  operations  can  occur  after  the  sequence  being  tested.  We  limit  the  tests  to  sequences 


1  *Thm  definition  was  first  used  in  |Kl.MW|.  The  definition  of  well-formedness  in  that  paper  was  different  from  the  one  that  was 
introduced  in  |LM|  and  that  we  use  here,  and  we  warn  readers  that  most  of  the  properties  proved  in  [FLMWJ  about  equieffeetive 
schedules  do  not  hold  for  this  paper 
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that  do  not  violate  well-formedness,  for  technical  reasons,  because  we  have  not  required  the  objects  to 
behave  sensibly  if  the  inputs  violate  well-formedness.  Clearly,  a  is  equicffective  to  /?  if  and  only  if  /?  is 
equieffective  to  a  and  in  this  case  we  say  that  a  and  0  are  equieffective  sequences.  We  also  have  an 
extension  result. 

Lemma  43:  If  a  and  $  are  equieffective  well-formed  sequences  of  operations  of  X,  and  0  is  a 
sequence  of  operations  of  X  such  that  a</>  and  fi<f>  are  well-formed,  then  a<i>  and  f)<t>  are 
equieffective. 

Proof:  This  is  immediate,  since  well-formed  extensions  of  a<)>  are  well-formed  extensions  of 
a.  □ 


Equieffectiveness  is  not  an  equivalence  relation,  but  we  do  have  a  restricted  transitivity  result. 

Lemma  44:  Let  £,  q  and  f  be  three  well-formed  sequences  of  deeds  at  X,  such  that  every 
deed  in  q  appears  in  either  {  or  f.  If  perform(£)  is  equieffective  to  perform^),  and  perform(q)  is 
equieffective  to  perform(f),  then  perform(f)  is  equieffective  to  perform(f). 

Proof:  Suppose  perform(£)  and  perform^)  are  equieffective,  and  that  perform(q)  and 
perform($)  are  equieffective.  In  order  to  prove  that  perform(f)  and  perform(f)  are  equieffective, 
we  must  take  any  sequence  of  operations  $  such  that  perform(£)/?  and  performed  are  well- 
formed,  and  show  that  performed  is  a  schedule  of  X  if  and  only  if  performed  is  a  schedule. 

By  the  definition  of  equieffectiveness,  and  the  transitivity  of  “if  and  only  if“,  it  suffices  to 
show  that  performed  is  well-formed-  But  by  Lemma  3,  d  must  be  either  perform(r)  or 
perform(r)CREATE(T),  where  the  first  components  of  all  the  deeds  in  r  (and  T  as  well,  if 
appropriate)  are  distinct  from  the  first  components  of  all  the  deeds  in  £  and  f.  By  the 
condition  on  q,  the  first  components  of  all  the  deeds  in  r  (and  T  as  well,  if  appropriate)  are 
distinct  from  the  first  components  of  the  deeds  in  q.  Thus  Lemma  3  completes  the  proof,  by 
showing  that  perform(q)d  is  well-formed.  □ 

7.1.1.  Commutativity 

Our  definition  of  commutativity  is  closely  based  on  the  one  introduced  by  Weihl  for  systems  without 
nesting  [We],  We  extend  his  work  slightly  by  ignoring  the  actual  state  of  the  data  object,  and  considering 
only  the  information  about  the  state  that  can  be  determined  by  later  tests. 


We  say  that  deeds  (T,v)  and  (T’,v’)  at  basic  object  X  commute  if  for  any  sequence  of  deeds  (  such  that 
both  perform(£(T,v))  and  perform(£(T’,v’))  are  well-formed  schedules  of  X,  then  perform(^T,vXT’,v’)) 
and  perform(£(T’,v’)(T,v))  are  equieffective  well-formed  schedules  of  X.  That  is,  we  can  consider  for  any 
deed  (T,v)  the  test  that  determines  if  a  schedule  of  X  can  be  extended  by  perform(T,v).  Then  (T,v)  and 
(T’,v’)  commute  if  whenever  X  passes  each  test,  it  passes  both  in  any  order,  and  furthermore,  no  later  test 
can  determine  which  order  was  used. 


To  illustrate  this  definition,  we  will  consider  an  object  X  representing  a  bank  account.  The  accesses  to 
X  are  of  the  following  kinds: 

•  balance?:  The  return  value  for  this  access  gives  the  current  balance. 

•  deposit-$a:  This  increases  the  balance  by  $a.  The  only  return  value  is  NIL. 
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•  witlidraw-$b:  This  reduces  the  balance  by  $b  if  the  result  will  not  be  negative.  In  this  case  the 
return  value  is  OK.  If  the  result  of  withdrawing  would  be  to  cause  an  overdraft,  then  the 
balance  is  left  unchanged,  and  the  return  value  is  FAIL. 

For  this  object,  it  is  clear  that  two  well-formed  schedules  that  leave  the  same  final  balance  in  the  account 
are  equieffective,  since  the  result  of  each  access  depends  only  on  the  current  balance.  Now  if  T  and  T’  are 
accesses  of  kind  deposit-$a  and  deposil-$b,  then  the  deeds  (T,NIL)  and  (T’,NIL)  commute.  To  see  this, 
suppose  perform(£{T,NIL))  and  perform(£(T’,NIL))  are  well-formed  schedules  of  X.  This  implies  that  £  is 
well-formed  and  contains  no  deed  with  first  component  T  or  first  component  T’.  Therefore  a  — 
perform(£(T,NIL)(T',NIL))  and  0  —  perform(£(T’,NIL)(T,NIL))  are  well-formed.  Also  since  perform(f)  is 
a  schedule  of  X,  so  are  each  of  a  and  (3 ,  since  a  deposit  can  always  occur.  Finally  the  balance  left  after 
each  of  a  and  /?  is  $(x+a+b),  where  $x  is  the  balance  after  perform(f),  so  a  and  are  equieffective. 

On  the  other  hand,  let  U  and  U’  be  distinct  accesses  of  kind  withdraw-$a  and  withdraw-$b  respectively. 
Then  (U,OK)  and  (U’,FAIL)  commute.  The  reason  is  that  if  perform(£(U,OK))  and  perform(£(U’,FAJL)) 
are  both  well-formed  schedules  then  we  must  have  a  <  x  <  b,  where  $x  is  the  balance  after  perform(f). 
In  this  situation  both  perform(£(U,OK)(U’,FAIL))  and  perform(£(U’,FAIL)(U,OK))  are  well-formed 
schedules  of  X,  which  result  in  a  balance  of  $(x-a),  and  so  are  equieffective.  However,  (U,OK)  and 
(U\ OK)  do  not  commute,  since  if  perform(£)  leaves  a  balance  of  $x,  where  max(a,b)  <  x  <  afb,  then 
perform(£(U,OK))  and  perform(£(U’,OK))  are  schedules  of  X,  but  perform({(U,OK)(U’,OK))  is  not  a 
schedule,  since  after  per  for  m(  £(U  ,OK))  the  balance  left  is  $(x-a),  which  is  not  sufficient  to  cover  the 
withdrawal  of  $b. 

This  example  demonstrates  a  significant  feature  of  the  approach  to  concurrency  control  that  was  taken 
in  [We],  and  adopted  in  this  paper.  We  allow  the  return  value  of  accesses  to  be  considered  in  determining 
commutativity,  and  thus  also  when  deciding  whether  the  accesses  can  be  allowed  to  proceed  concurrently. 
Traditional  database  management  systems  have  used  an  architecture  where  a  lock  manager  first 
determines  whether  an  access  is  to  proceed  or  be  delayed,  and  only  later  is  the  response  determined.  Our 
approach  models  both  obtaining  locks  and  choosing  a  response  as  preconditions  on  the  operation  of  giving 
the  response.  In  our  example,  we  show  that  it  is  acceptable  to  allow  a  successful  withdrawal  to  proceed 
concurrently  with  one  that  fails.  By  doing  so,  we  obtain  concurrency  that  is  unavailable  if  return  values 
of  accesses  are  not  considered  in  determining  commutativity.  However  we  note  that  our  arguments  for 
serial  correctness  in  section  8  merely  require  that  non-commuting  accesses  be  prevented  from  acting 
concurrently.  They  do  not  require  that  commuting  accesses  be  allowed  to  proceed  concurrently.  Thus  our 
arguments  still  prove  the  correctness  of  traditional  systems,  where  locks  are  obtained  without  regard  to 
the  value  that  will  be  returned. 

The  next  lemma  shows  how  the  defining  property  of  commutativity  carries  through  to  sequences  of 
deeds. 


Lemma  45:  If  ?  and  <?  are  sequences  of  deeds  at  X  such  that  each  deed  in  $  commutes  with 
each  deed  in  <?,  and  £  is  a  sequence  of  deeds  such  that  both  perform(£f)  and  perform{&’)  are 
well-formed  schedules  of  X,  then  perform^#1)  and  perform(£f’j)  are  equieffective  well-formed 
schedules  of  X. 

7.2.  Transparency 

We  say  that  a  deed  (T,v)  at  X  is  transparent  if  for  any  sequence  of  deeds  $  such  that  perform(£(T,v))  is 
a  well-formed  schedule  of  X,  then  perforra(£(T,v))  and  perform(£)  are  equieffective  well-formed  schedules 
of  X. 

We  extend  the  defining  property  to  collections  of  deeds  in  the  following  lemma. 

Lemma  48*  Let  q  be  a  sequence  of  deeds  at  X  such  that  perform(q)  is  a  well-formed 
schedule  of  X,  and  let  $  be  a  subsequence  of  q,  such  that  every  deed  in  q-£  is  transparent.  Then 
perform(q)  and  perform(£)  are  equieffective  well-formed  schedules  of  X. 

The  next  lemma  shows  how  transparency  is  related  to  commutativity. 

Lemma  47*  Let  (T,v)  and  (T’,v’)  be  transparent  deeds  at  X  such  that  T  T’.  Then  (T,v) 
commutes  with  (T’,v’). 

Proof:  Suppose  £  is  a  sequence  of  deeds  at  X  such  that  perform(£(T,v))  and 
perform(£(T\v’))  are  well-formed  schedules  of  X.  Therefore  no  deed  in  £  has  T  or  T’  as  first 
component,  and  all  the  deeds  in  £  have  distinct  first  components.  Therefore 
perform(£(T,v)(T\v’))  and  perform(£(T,,v,)(T1v))  are  well-formed  sequences  of  operations  of 
X.  Now  perform(£(T,v))  and  perform(£)  are  equieffective,  since  (T,v)  is  transparent.  Since 
perform(£)perform(T’,v’)  is  a  schedule  of  X,  the  definition  of  equieffectiveness  implies  that 
perform(£(T,v))perform(T’,v,)>»>perforin(£(T,v)(T’,v’))  is  also  a  schedule  of  X.  Similarly  the 
fact  that  (T’,v’)  is  transparent  implies  that  perform(£(T’,v’XT,v))  is  a  schedule  of  X.  By 
Lemma  48,  each  of  perform^T.vXT’.v’))  and  perform(£(T\v’XT,v))  are  equieffective  to 
perform(£).  Lemma  44  now  shows  that  they  are  equieffective  to  each  other,  as  required.  □ 

8.  Conflict-Based  Locking  Objects 

Given  a  basic  object  X  and  a  binary  relation  CONFLICT  on  pairs  of  deeds  at  X,  we  construct  a  generic 
object  automaton  W(X)  using  conflict-based  locking,  where  CONFLICT  is  used  to  determine  when  locks 
conflict.  We  show  that  if  CONFLICT  contains  all  pairs  of  non-commuting  deeds,  then  the  conflict-based 
locking  object  is  dynamic  atomic.  Note  that  in  many  implementations  there  will  be  pairs  that  commute 
but  are  nonetheless  in  CONFLICT  (e.g.,  in  exclusive  locking,  CONFLICT  includes  all  pairs  of  deeds  at 
X!),  but  this  does  not  invalidate  our  correctness  proof. 

W(X)  has  the  following  operations. 

Input  operations: 

CREATE(T),  for  T  an  access  to  X 
INFORM  _  COMMIT  _  AT(X)OF( T),  T  y4  T„ 

INFORM  _  ABORT_  AT(X)OF(T),  T  /  T„ 

Output  operations: 


REQUEST_COMMIT(T,v),  for  T  an  access  to  X 

A  state  s  of  W(X)  has  components  s.create_ requested,  s.run  and  s. intentions.  Of  these, 
create _  requested  and  run  are  sets  of  transactions,  initially  empty,  and  intentions  is  a  function  from 
transactions  to  sequences  of  deeds  at  X,  initially  mapping  every  transaction  to  the  empty  sequence  A. 
When  (T,v)  is  a  member  of  s.intentions(U),  we  say  that  U  holds  a  (T,v)-lock.  Given  a  state  s  and  a 
transaction  T  %ve  also  define  the  sequence  total(s,T)  of  deeds  by  the  recursive  definition  total(s,T0)  == 
s.intentions(TQ),  total(s,T)  =  total(s,parent(T))s.intentions(T).  Thus  perform(total(s,T))  is  the  sequence 
of  operations  obtained  by  concatenating  the  values  of  intentions  along  the  chain  from  to  T,  and  then 
replacing  each  (U,u)  by  CREATE(U)REQUEST_COMMIT(U,u);  as  we  will  see,  when  T  is  an  access  to  X 
this  records  a  sequence  of  operations  of  basic  object  X  that  leads  to  a  state  of  the  basic  object  which  is 
used  as  the  "current"  state  when  determining  the  response  to  T. 

The  transition  relation  of  W(X)  is  given  by  all  triples  (s’,7r,s)  satisfying  the  following  pre-  and 
postconditions,  given  separately  for  each  n.  As  before,  any  component  of  s  not  mentioned  in  the 
postconditions  is  the  same  in  s  as  in  s’. 

CREATE(T),  T  an  access  to  X 
Postcondition: 

s.create_ requested  =  s’. create_ requested  U  {T} 

lNFORM_COMMIT_AT(X)OF(T),  T^TQ 
Postcondition: 

s.intentions(T)  =  A 

s.intentions(parent(T))  =  s’.intentions(parent(T))s’.intentions(T) 
s.intentions(U)  =  s’.intentions(U)  for  U^T,  parent(T) 

INFORM_ABORT_AT(X)OF(T),  T  ^  TQ 
Postcondition: 

s.intentions(U)  =  A,  U  G  descendants(T) 
s.intentions(U)  =  s’.intentions(U),  U  £  descendants(T) 

REQUEST _ COMMIT(T, v) ,  T  an  access  to  X 
Precondition: 

T  €  s’. create _  requested  -  s’. run 

for  every  U  such  that  U  £  ancestors(T),  and  every  (T’,v’)  in  s’.intentions(U): 

((T,v),(T’,v’))  £  CONFLICT 
perform(total{s’,T)(T,v))  is  a  schedule  of  basic  object  X 
Postcondition: 

s.run  =  s’.run  U  {T} 
s.intentions(T)  =  s’.intentions(T)(T,v) 
s.intentions(U)  =  s’.intentions(U)  for  U  T 

When  an  access  transaction  is  created,  it  is  added  to  the  set  create _ requested.  A  response  containing 

return  value  v  to  an  access  T  can  be  returned  only  if  the  access  has  been  requested  but  not  yet  responded 
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to,  every  holder  of  a  conflicting  lock  is  an  ancestor  of  T,  and  v  is  a  value  such  that  perform(T,v)  can 
occur  as  operations  of  basic  object  X  from  a  state  of  basic  object  X  following  the  schedule 
perform(total(s’,T)).  When  a  response  is  given,  the  access  transaction  is  added  to  run  and  the  deed  (T,v) 
is  appended  to  intentions(T)  to  indicate  that  the  (T,v)-lock  was  granted.  When  a  Conflict-Based  Locking 
object  is  informed  of  the  abort  of  a  transaction,  it  removes  all  locks  held  by  descendants  of  the 
transaction.  When  it  is  informed  of  a  commit,  it  passes  any  locks  held  by  the  transaction  to  the  parent, 
appending  them  at  the  end  of  the  parents  intentions  list. 

We  have  the  following  obvious  result,  since  W(X)  has  the  appropriate  operations  and  preserves  well- 
formedness: 

Lemma  48:  W(X)  is  a  generic  object. 

8.1.  Properties  of  W(X) 

We  first  note  that  the  holders  of  conflicting  locks  must  always  be  related.  This  is  guaranteed  when  a 
lock  is  granted,  and  is  maintained  as  locks  are  passed  up  from  child  to  parent. 

Lemma  48:  If  a  is  a  well-formed  schedule  of  W(X),  s  is  the  state  of  W(X)  after  a,  T  and  T* 
are  unrelated  transactions,  (U,u)  is  in  s.intentions(T),  and  (U’,u’)  is  in  s.intentions(T’),  then 
((U,u),(U’,u’))  g  CONFLICT. 

The  algorithm  as  described  above  does  not  use  all  the  information  available  to  the  object  about  the  fate 
of  transactions,  because  it  does  not  store  the  fact  that  an  INFORM_COMMIT  or  INFORM_ABORT 
operation  has  occurred.  Thus  we  introduce  some  terms  to  describe  the  information  W(X)  uses  about 
commits,  aborts  and  return  order  of  transactions  after  a  sequence  a  of  operations  of  W(X).  If  or  is  a 
sequence  of  operations  of  W(X),  T  is  an  access  to  X,  and  T’  is  an  ancestor  of  T,  we  say  that  T  is 
lock-committed  at  X  to  T'  in  a,  if  a  contains  a  subsequence  $  consisting  of  an 
INFORM  _  COMMIT _AT(X)OF(U)  event  for  every  U  that  is  an  ancestor  of  T  and  a  proper  descendant 
of  T’,  arranged  in  ascending  order  (so  the  INFORM _ COMMIT  for  parent(U)  is  preceded  by  that  for  U). 
If  a  is  a  well-formed  sequence  of  operations  of  W(X),  T  is  an  access  to  X,  and  T’  is  any  transaction,  we 
say  that  T  is  lock-visible  at  X  to  T’  in  a  if  T  is  lock-committed  at  X  to  lca(T,T’).  It  is  obvious  that  if  T 
is  lock-committed  at  X  to  T’  in  a,  then  T  is  committed  at  X  to  T’  in  cr.  Similarly  if  T  is  lock-visible  at 
X  to  T’  in  a  then  T  is  visible  at  X  to  T’  in  or. 

Given  a  sequence  a  of  operations  of  W(X),  we  define  a  binary  relation  lock-return-at-X^a)  on  accesses 
to  X,  where  (U,U’)  €  return-at-XT(a)  exactly  when  U  ^  U’,  «  contains  both  REQUEST  _COMMIT(U,v) 
and  REQUEST _COMMIT(U’,v’)  for  some  values  v  and  v’,  and  U  is  lock-visible  at  X  to  U’  in  a’,  where 
a’  is  the  longest  prefix  of  a  not  containing  REQUEST_COMMIT(U’,v’).  We  will  also  consider  the 
induced  relations  lock-return-at-XE(a)  on  the  events  of  a,  and  lock-return-at-XD(o)  on  deeds  at  X.  The 
first  is  defined  by  the  condition  that  (^,ir)  €  lock-return-at-XE(o)  if  and  only  if  <f>  and  n  are  events  of  a 
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mentioning  accesses  U  and  U’  respectively,  and  (U,U’)  6  lock-return-at-XT(a).  Similarly,  we  define  the 
second  by  ((U,v),(U’,v’))  €  lock-return-at-XD(a)  if  and  only  if  €  lock-relurn-at-Xgfa),  where 

0=REQUEST  _  COMMIT(  U,v )  and  jt=  REQUEST _COMMIT(U\v’).  It  is  clear  that 

lock-return- at- Xj.(a)  is  a  subrelation  of  return-at-XT(a). 

The  following  lemma,  which  can  be  proved  by  a  straightforward  induction,  shows  which  locks  are  held 
by  a  transaction  after  a  schedule  of  W(X). 

Lemma  60s  Let  a  be  a  well-formed  schedule  of  W(X),  and  s  the  state  of  W(X)  reached  by 
applying  o  to  the  initial  state.  Let  T  be  an  access  to  X  such  that  REQUEST  _  OOMMIT( T , v ) 
occurs  in  a  and  T  is  not  an  orphan  at  X  in  a,  and  let  T’  be  the  highest  ancestor  of  T  such  that 
T  is  lock-committed  at  X  to  T’  in  a.  Then  (T,v)  is  a  member  of  s.intentions(T’).  Conversely, 
if  (U,u)  is  an  element  of  s.intentions(U’)  then  U  is  a  descendant  of  U’, 
REQUEST  _COMMIT(U,u)  occurs  in  o,  and  U’  is  the  highest  ancestor  of  U  to  which  U  is 
lock-committed  at  X  in  a. 


Now  for  the  main  result,  which  shows  that,  provided  the  relation  CONFLICT  includes  all  non¬ 
commuting  deeds,  certain  sequences  of  operations,  extracted  from  a  well-formed  schedule  of  W(X),  are 
well-formed  schedules  of  basic  object  X.  The  extra  conclusion,  that  some  of  these  schedules  are 
equieffective,  is  needed  to  carry  out  the  induction  step  of  the  proof  of  this  lemma.  We  say  that  a  binary 
relation  CONFLICT  on  deeds  at  X  is  permissible  if  for  any  two  deeds  (T,v)  and  (T’,v’)  at  X  that  do  not 
commute,  ((T,v),(T’,v’))  €  CONFLICT. 

Lemma  51s  Suppose  CONFLICT  is  a  permissible  binary  relation  on  deeds  at  X.  Let  W(X) 
be  the  Conflict-Based  Locking  object  constructed  using  CONFLICT,  and  let  a  be  a  well- 
formed  schedule  of  W(X).  Let  Z  be  a  set  of  deeds  at  X  such  that  for  all  (T,v)  €  Z,  a  contains 
REQUEST _COMMIT(T,v),  T  is  not  an  orphan  at  X  in  a,  and  whenever  ((T’,v’),(T,v))  € 
lock-return-at-XD(o)  then  (T’,v’)  €  Z.  Let  £  and  if  be  total  orderings  of  Z  such  that  each  is 
consistent  with  lock-return-at-Xjj(a).  Then  perform(()  and  perform(if)  are  both  well-formed 
schedules  of  basic  object  X.  Furthermore,  perform(f)  and  perform(if)  are  equieffective. 

Proofs  The  proof  will  use  induction  on  the  site  of  the  set  Z.  The  basis  case,  when  Z  is 
empty,  is  trivial.  Otherwise,  suppose  Z  contains  k  deeds,  and  the  lemma  has  been  proved  for 
all  sets  of  k-1  deeds.  Let  (U,u)  denote  the  last  element  of  (,  and  let  Z’  —  Z  -  {(U,u)}.  Also  let 
£=£’(U,u),  and  »f=»71(U,u)if2.  Now  let  s’  denote  the  state  of  W(X)  after  o’,  where  a’  is  the 
longest  prefix  of  a  not  containing  REQUEST  _COMMIT(U,u).  Finally,  let  f1=total(s’,U),  and 
let  denote  some  total  ordering,  consistent  with  lock-return-at-Xjj(o),  of  the  deeds  in  Z  - 
(totals’, U)  U  {(U,u)}). 

Clearly  Z’  is  a  set  of  k-1  deeds  that  satisfies  the  conditions  of  the  lemma,  since  there  is  no 
deed  (U’,u’J  in  Z  such  that  ((U,u),(U’,u’))  €  lock-return-at-Xpfa).  Also  and  *fj*y2  are  total 
orderings  of  Z’  consistent  with  lock-return-at-Xp(a).  Furthermore  by  Lemma  50  the  deeds  in 
totals’, U)  are  exactly  those  (U’,u’)  such  that  ((U’,u’),(U,u))  €  lock-return-at-X^a),  and  their 
order  is  consistent  with  lock-return-at-XD(o).  Since  for  every  deed  (U’,u’)  in  f,,  and  every  deed 
(U”,u”)  in  f2,  ((U”,u”),(U’,u’))  £  lock-return-at-Xpfa),  we  have  that  f,f2  is  also  a  total 
ordering  of  V  consistent  with  lock-return-at-XD(a).  The  induction  hypothesis  thus  shows  that 
perform(£’),  perform(»fji?2),  and  perform(f(f2)  are  all  equieffective,  well-formed  schedules  of 
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basic  object  X. 

We  now  begin  the  proof  that  perform(£)  and  perforin(q)  are  well-formed  schedules  of  X  We 
first  show  that  (U,u)  commutes  with  every  deed  (U”,u”)  in  <r2-  There  are  two  possibilities: 
either  REQUEST _COMMIT(U”,u”)  precedes  REQUEST _ COMMIT(U ,u)  in  a,  or  else 
REQUEST_COMMIT(U,u)  precedes  REQUEST_COMMIT(U”,u”)  in  a.  In  the  first  case,  let 
V  denote  the  highest  ancestor  of  U”  to  which  U”  is  lock-committed  at  X  in  o’.  By  Lemma  50, 
(U”,u”)  €  s’.intentions(V),  but  by  definition  of  f2  V  is  not  an  ancestor  of  U.  Therefore,  by  the 
preconditions  for  REQUEST  _COMMIT(U,u),  which  is  enabled  in  state  s’,  we  must  have  that 
((U,u),(U”,u”))  t  CONFLICT,  and  therefore  in  this  case  (U,u)  and  (U”,u”)  commute.  In  the 
second  case,  let  t  denote  the  state  of  W(X)  after  a”,  the  longest  prefix  of  a  not  containing 
REQUEST  _COMMIT(U”,u”).  Also  let  V  denote  the  highest  ancestor  of  U  to  which  U  is  lock- 
committed  at  X  in  a”,  so  that  (U,u)  €  t.intentions(V).  Now  V  is  not  an  ancestor  of  U”,  as 
otherwise  ((U,u),(U”,u”))  €  lock-return-at-XD(a),  contradicting  the  assumption  that  (U,u)  was 
the  last  element  in  £.  Thus  by  the  preconditions  for  REQUEST _COMMIT(U”,u”)  as  an 
operation  of  W(X),  ((U”,u”),(U,u))  g  CONFLICT,  so  in  this  case  also,  (U,u)  and  (U”,u”) 
commute. 

Note  that  by  the  preconditions  for  REQUEST  _COMMIT(U,u)  as  an  operation  of  W(X).  we 
have  that  perform(total(s’,U)(U,u))  is  a  schedule  of  basic  object  X,  which  is  clearly  well- 
formed,  since  a  is  well-formed.  That  is,  perform(fj(U,u))  is  a  well-formed  schedule  of 
X.  However,  we  showed  above  that  perform(q?2)  is  a  well-formed  schedule  of  X.  Since  (U,u) 
commutes  with  every  deed  in  f2,  we  have  by  Lemma  45  that  perform^ f2(U,u))  is  a  well- 
formed  schedule  of  X.  Since  we  saw  that  performf^fj)  is  equieffective  to  perform(f’),  and  since 
perform(£)=  perform(f’(U,u))  is  clearly  well-formed,  Lemma  43  shows  that  perform(£)  is  a 
schedule  of  X  that  is  equieffective  to  perform(f1f2(U,u)).  Similarly,  since  perform(f’)  is 
equieffective  to  perform(iy1^2),  perform(()  is  equieffective  to  perform(u,U2(U,u)).  This 
completes  the  proof  that  perform(()  is  a  well-formed  schedule  of  X.  By  a  symmetrical 
argument,  perform(u)  is  a  well-formed  schedule  of  X. 

Since  perform(ij)  is  a  well-formed  schedule  of  X,  we  deduce  that  its  prefix  perform(u1(U,u))  is 
also  a  well-formed  schedule  of  X.  However  the  induction  hypothesis  showed  that  perform(q1i)2) 
is  a  well-formed  schedule  of  X.  Since  every  deed  in  is  contained  in  ijj,  every  deed  in  »i2  is 
contained  in  ?2,  and  so  (U,u)  commutes  with  every  deed  in  ij.,.  Therefore  perform(q)= 
performfa^U.ujfjj)  is  equieffective  to  perform(Uj»?2(U,u)),  by  Lemma  45.  Since 
perform(!}j»>2(U,u))  is  equieffective  to  perform(£),  we  use  Lemma  44  to  deduce  that  perform(i/) 
is  equieffective  to  perform(|),  completing  the  proof.  □ 

Now  we  can  prove  that  our  algorithm  produces  local-dynamic  atomic  generic  objects. 

Theorem  52i  Suppose  CONFLICT  is  a  permissible  binary  relation  on  deeds  at  X.  Let  W(X) 
be  the  Conflict-Based  Locking  object  constructed  using  CONFLICT.  Then  W(X)  is  local- 
dynamic  atomic. 

Pro of*  Let  07  be  a  well-formed  schedule  of  W(X),  and  T  a  transaction  that  is  not  an  orphan 
at  X  in  07.  Let  $  be  a  reordering  of  visible-at-X(a7,T)  that  is  consistent  with  return-at-X£(a) 
and  that  is  a  well-formed  sequence  of  operations  of  basic  object  X.  We  must  show  that  $  is  a 
schedule  of  basic  object  X.  Consider  the  set  Z  of  deeds  (U,u)  such  that 
REQUEST _COMMIT(U,u)  occurs  in  0,  and  let  f  denote  the  unique  total  ordering  of  Z  in 
which  (U,u)  precedes  (U’,u’)  exactly  when  REQLTEST_COMMIT(U,u)  precedes 
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REQUEST_COMMIT(U’,u’)  in  0.  Lemma  3  shows  that  0  is  equal  to  either  perform(f)  or 
pcrform(f)CREATE(T’)  for  some  access  T’.  We  observe  that  since  T’  is  visible  at  X  to  T  in  07, 
but  <*7  does  not  contain  a  REQUEST _  COMMIT  operation  for  T\  and  so  does  not  contain  an 
INFORM_COMMIT  operation  for  T\  we  can  deduce  that  T’  must  be  equal  to  T. 

We  now  show  that  ?  satisfies  the  conditions  given  in  Lemma  51,  and  thus  that  perform(f)  is  a 
schedule  of  basic  object  X.  That  is,  suppose  (U,u)  €  Z.  We  will  demonstrate  that  aq  contains 
REQUEST_COMMIT(U,u),  that  U  is  not  an  orphan  at  X  in  a%  and  that  whenever 
((U’,u’),(U,u))  €  lock-return-at-XD(aq),  then  (U’,u’)  €  Z.  We  will  also  demonstrate  that  the 
ordering  £  is  consistent  with  lock-return-at-X^a'y),  by  showing  that  the  latter  is  a  subrelation 
of  the  former. 

Since  (U,u)  €  Z,  REQUEST  _COMMIT(U,u)  occurs  in  0,  and  thus  in  visible-at-X(a'/,T)  and 
therefore  in  <*7.  Since  U  is  visible  at  X  to  T  in  a%  and  T  is  not  an  orphan  at  X  in  07,  we 
deduce  that  U  is  not  an  orphan  at  X  in  07.  If  ((U’,u*),(U,u))  €  lock-return-at-Xpfaq),  then  07 
must  contain  REQUEST  _COMMIT(U’,u’)  and  also  U’  is  lock-visible  at  X  to  U  in  a  prefix  of 
or 7.  Thus  U’  is  visible  at  X  to  U  in  07,  and  therefore  U’  is  visible  at  X  to  T  in  or 7.  We  deduce 
that  the  REQUEST  _COMMTr(U\u’)  event  is  in  visible-at-X(a7,T),  and  therefore  in  0.  That 
is  (U’,u’)  €  Z,  as  required.  We  also  want  to  show  that  if  ((U’,u’),(U,u))  € 
lock-return-at-Xj^oq),  then  (U’,u’)  precedes  (U,u)  in  f,  that  is,  that 
REQUEST  _COMMIT(U’,u’)  precedes  REQUEST  _COMMIT(U,u)  in  0.  Since  the  order  of 
events  in  0  is  consistent  with  return-at~Xg(cr),  it  suffices  to  show  that  (^,w)  €  return- at-X^  a) 
where  <t>  =  REQUEST_COMMIT(U’,u’)  and  jt  =  REQUEST_COMMIT(U,u).  However  if  we 
denote  by  a'  the  prefix  of  a  preceding  jr,  then  we  know  that  U’  is  lock-visible  at  X  to  U  in  a’, 
and  thus  U’  is  visible  at  X  to  U  in  or’,  which  establishes  the  fact  that  ((U’,u’),(U,u))  € 
return- at-XD(a),  and  thus  that  €  return-at-Xg(a). 

Thus  the  demonstrations  in  the  previous  paragraph  enable  us  to  deduce  that  perform(f)  is  a 
schedule  of  basic  object  X.  Since  0  is  either  perform(f)  or  perform(f)CREATE(T),  it  is  now 
immediate  that  0  is  a  schedule  of  basic  object  X,  completing  the  proof  that  W(X)  is  local- 
dynamic  atomic.  □ 

An  immediate  consequence  of  Theorem  52,  Lemma  42  and  Corollary  34  is  that  if  S  is  a  Gonflict-Bastd 
Locking  eyetem,  that  is  a  generic  system  in  which  each  generic  object  is  a  Conflict-Based  Locking  object 
for  any  permissible  choice  of  CONFLICT  relation  for  that  object,  then  S  is  serially  correct  for  all  non- 
orphan  transactions. 


9.  R/W  Locking  objects 

We  mentioned  earlier  that  the  algorithm  for  general  conflict-based  locking  combines  the  techniques  used 
by  Weih)  in  the  absence  of  nesting  with  those  used  by  Moss  for  Read/Write  locking  in  nested  transaction 
systems.  In  this  section,  we  recall  the  R/W  Locking  object  automaton  M(X),  constructed  in  (FLMW]  as  a 
formal  model  for  an  object  using  Moss’  algorithm  for  concurrency  control  and  recovery  in  a  nested 
transaction  system.  We  show  that  if  CONFLICT  is  chosen  to  include  all  pairs  of  deeds  except  those  whose 
first  components  are  distinct  read  transactions,  then  the  object  W(X)  is  a  suitable  specification  for  M(X), 
in  the  sense  that  any  well-formed  schedule  of  M(X)  is  a  well-formed  schedule  of  W(X).  In  fact,  the 
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construction  of  M(X)  is  similar  to  that  of  W(X),  the  major  difference  being  that  the  list  of  deeds  stored  in 
the  intentions  component  of  the  state  of  W(X)  is  replaced  by  a  single  version  of  the  state  of  basic  object 
X,  stored  in  the  map  component  of  the  state  of  M(X). 


In  order  to  construct  M(X)  we  need  a  classification  of  all  the  accesses  to  X  into  two  classes,  called 
respectively  the  read  accesses  and  the  write  accesses.  We  say  that  this  classification  is  permissible  if 
whenever  T  is  a  read  access,  then  (T,v)  is  a  transparent  deed  at  X  for  any  v.  If  £  is  a  sequence  of  deeds  at 
X,  we  let  write(()  denote  the  subsequence  consisting  of  those  deeds  whose  first  components  are  write 
accesses.  When  the  classification  is  permissible,  Lemma  46  implies  that  if  perform(()  is  a  well-formed 
schedule  of  X,  then  perform(write{£))  is  an  equieffective  well-formed  schedule  of  X. 


We  first  reproduce  the  construction  of  M(X)  from  [FLMW].  M(X)  has  the  following  operations. 

Input  operations: 

CREATE(T),  for  T  an  access  to  X 
INFORM  _  COMMIT  _AT(X)OF(T),  T  /  TQ 
INFORM  _  ABORT  _  AT(X)OF(T),  T  yd  T0 
Output  operations: 

REQUEST  _COMMIT(T,v),  for  T  an  access  to  X 

A  state  s  of  M(X)  consists  of  the  following  five  components:  s.write-lockholders,  s. read-lockholders, 

s.create_ requested,  and  s.run,  which  are  sets  of  transactions,  and  s.map,  which  is  a  function  from  s.write- 

lockholders  to  states  of  the  basic  object  X.  We  say  that  a  transaction  in  write-lockholders  holds  a 

write-lock,  and  similarly  that  a  transaction  in  read-lockholders  holds  a  read-lock.  We  say  two  locks 

conflict  if  they  are  held  by  different  transactions  and  at  least  one  is  a  write-lock.  The  initial  states  of 

M(X)  are  those  in  which  write-lockholders  =  {Tfl}  and  map(T0)  is  an  initial  state  of  the  basic  object  X, 

and  the  other  components  are  empty.  The  transition  relation  of  M(X)  is  given  by  all  triples  (s’,ir,s) 

satisfying  the  following  pre-  and  postconditions,  given  separately  for  each  it.  As  before,  any  component  of 

s  not  mentioned  in  the  postconditions  is  the  same  in  s  as  in  s’. 

CREATE(T),  T  an  access  to  X 
Postcondition: 

s.create_ requested  =  s’. create _  requested  u  {T} 

INFORM  _  COMMIT  _AT(X)OF(T),  T  yd  TQ 
Postcondition: 

if  T  6  s’.write-lockholders  then 
begin 

s.write-lockholders  =  (s’.write-lockholders  -  {T})  U  (parent(T)} 
s.map(U)  =  s’.map(U)  for  U  €  s. write-lockholders  -  (parent(T)} 
s.map(parent(T))  —  s’.map(T) 
end 

if  T  €  s’. read-lockholders  then 
begin 


> 
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s.read-lockholders  =  (s’  .read-lockholders  -  {T})  U  (parent(T)} 
end 

INFORM  _  ABORT  _  AT(X)OF(T) ,  T  /  T„ 

Postcondition: 

s.write-lockholders  =  s’. write- lockholders  -  descendants(T) 
s. read-lockholders  =  s’. read-lockholders  -  descendants(T) 
s.map(U)  =  s’.map(U)  for  all  U  €  s.write-lockholders 

REQUEST  _COMMIT(T,v)  for  T  a  write  access  to  X 
Precondition: 

T  €  s’. create  _  requested  -  s’. run 

s’.write-lockholders  U  s’. read-lockholders  C  ancestors(T) 
there  are  states  t,  t’  of  basic  object  X  so  that 

(s’.map(least(s’.write-lockholders)),CREATE(T),t) 
and  (t,REQUEST_COMMIT(T,v),t’) 
are  in  the  transition  relation  of  basic  object  X 
Postcondition: 

s.run  =  s’. run  u  {T} 

s.write-lockholders  =>  s’.write-lockholders  U  {T} 
s.map(U)  =  s’.map(U)  for  all  U  €  s.write-lockholders  -  {T} 
s.map(T)  =  t’ 

REQUEST  _COMMIT(T,v)  for  T  a  read  access  to  X 
Precondition: 

T  €  i’.create_  requested  -  s’. run 

s’. write- lockholders  C  ancestors(T) 

there  are  states  t,  t’  of  basic  object  X  so  that 

(s’.map(least(8’.write-lockholden)),CREATE(T),t) 
and  (tfREQUEST_COMMn,(T,v)ft’) 
are  in  the  transition  relation  of  basic  object  X 
Postcondition: 

s.run  =  s’.run  U  {T} 

s. read-lockholders  =  s’. read-lockholders  U  {T} 


It  is  clear  that  a  R/W  Locking  object  preserves  well-formedness,  and  so  is  a  generic  object. 

When  an  access  transaction  is  created,  it  is  added  to  the  set  create-requested.  A  response  containing 
return  value  v  to  an  access  T  can  be  returned  only  if  the  access  has  been  requested  but  not  yet  responded 
to,  every  holder  of  a  conflicting  lock  is  an  ancestor  of  T,  and  v  is  a  value  that  can  be  returned  by  basic 
object  X  in  the  response  to  T  from  a  state  obtained  by  performing  CREATE(T)  in  the  state  that  is  the 
value  of  map  at  the  least  member  of  write-lockholders.  When  a  response  is  given,  the  access  transaction 
is  added  to  run  and  granted  the  appropriate  lock,  and  if  the  transaction  is  a  write  access,  the  resulting 
state  is  stored  as  map(T).  If  the  transaction  is  a  read  access,  no  change  is  made  to  the  stored  state  of  the 
basic  object  X,  i.e.  to  map. 
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When  a  R/W  Locking  object  is  informed  of  the  abort  of  a  transaction,  it  removes  all  locks  held  by 

descendants  of  the  transaction.  When  it  is  informed  of  a  commit,  it  passes  any  locks  held  by  the 

1  ** 

transaction  to  the  parent,  and  also  passes  the  version  stored  in  map,  if  there  is  one. 

We  use  the  same  terms  (with  the  same  definitions)  to  describe  which  transactions  are  lock-committed  at 
X,  aborted  at  X,  etc.  that  we  used  tor  W(X). 


Here  are  some  simple  facts  about  the  state  of  M(X)  after  a  schedule  a,  each  easily  proved  by  induction 
on  the  length  of  the  schedule. 

Lemma  5S:  Let  a  be  a  schedule  of  M(X),  and  s  a  state  of  M(X)  reached  by  applying  a  to  an 
initial  state.  Suppose  T  €  s.write-lockbolders  and  T’  6:  s.read-lockholders  U  s. write- lockholders 
Then  either  T  is  an  ancestor  of  T’  or  else  T*  is  an  ancestor  of  T. 

Lemma  54:  Let  a  be  a  well-formed  schedule  of  M(X),  and  s  a  state  of  M(X)  reached  by 
applying  a  to  an  initial  state.  If  T  is  an  access  to  X  such  that  REQUEST  _COMMIT(T,v) 
occurs  in  a  and  T  is  not  an  orphan  at  X  in  a,  let  T'  be  the  highest  ancestor  of  T  such  that  T 
is  lock-committed  at  X  to  T’  in  a.  Then  if  T  is  a  write  access,  T’  must  be  a  member  of  s.write- 
lockholders,  while  if  T  is  a  read  access,  T’  must  be  a  member  of  s.read-lockholders.  Conversely, 
if  T’  is  a  member  of  s.write-lockbolders,  then  there  is  some  write  access  T  to  X  such  that 
REQUEST _ COMMIT(T.v)  occurs  in  a,  T  is  not  an  orphan  at  X  in  a,  and  T’  is  the  highest 
ancestor  of  T  such  that  T  is  lock-committed  at  X  to  T’  in  a.  Similarly  if  T’  is  a  member  at 
s.read-lockholders,  then  there  is  some  read  access  T  to  X  such  that 
REQUEST _COMMIT(T,v)  occurs  in  a,  T  is  not  an  orphan  at  X  in  a,  and  T’  is  the  highest 
ancestor  of  T  such  that  T  is  lock-committed  at  X  to  T’  in  a. 


g.l.  The  relationship  between  M(X)  and  W(X) 

Now  we  construct  a  relation  CONFLICT  between  deeds  at  X,  by  defining  ((T,v),(T’,v’))  e  CONFLICT 
unless  T  and  T’  are  distinct  read  accesses  to  X.  We  consider  the  conflict-based  locking  object  W(X) 
constructed  using  this  relation.  If  the  classification  of  accesses  used  by  M(X)  is  permissible,  then  Lemma 
47  implies  that  any  pair  of  deeds  that  do  not  commute  are  in  the  relation,  hence  CONFLICT  is 
permissible  and  so  W(X)  is  dynamic  atomic.  The  following  results  show  how  the  behavior  of  M(X)  is 
related  to  that  of  W(X).  The  first  lemma  is  straightforward,  since  the  postconditions  for  each  operation 
of  M(X)  are  similar  to  the  postconditions  for  the  same  operation  of  W(X).  The  second  establishes  the 
correspondence  between  the  state  of  X  stored  by  M(X)  in  map,  and  the  schedule  of  X  stored  by  W(X)  in 
intentions.  The  third  is  the  result  we  want,  which  shows  that  in  an  environment  that  ensures  well- 
formedness  (in  particular  in  a  generic  system)  any  behavior  of  M(X)  is  a  possible  behavior  for  W(X) 
provided  M(X)  is  constructed  using  a  permissible  classification.  Thus  M(X)  is  local-dynamic  atomic  if  the 
classification  used  is  permissible. 

13lf  the  reader  wishes  to  eompare  our  rersioa  of  tk«  algorithm  with  that  in  [Mo|,  the  following  may  be  useful.  Mom  gives  Uk 
name  ’the  associated  atatr*  for  object  X  sad  tow  notion  T  to  what  wo  call  a.maptT’)  where  T  is  the  least  ancestor  of  T  in 
s.write-lockbolders,  sad  he  calls  a.map(leest(s  wrMc-li»-kkr><dtr»))  'the  current  state*  «,r  X.  AI-,0,  he  removes  a  read-loch  wfcea  the 
owner  nleo  holde  a  write-lock  (tbit  ie  aa  optimisation  that  does  not  affect  the  correctness  proof).  Moat  also  allows  iateraal 
traaaactloaa  to  directly  access  objects,  whereat  we  allow  oalj  leaf  transactions  to  perforin  data  access. 
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Lemma  55:  Let  o  be  a  welt-formed  schedule  of  M(X)  that  is  also  a  well-formed  schedule  of 
W(X).  Let  s  be  a  state  of  M(X)  reached  by  applying  a  to  an  initial  state  of  M(X),  and  let  t  be 
the  unique  state  of  W(X)  reached  by  applying  a  to  the  initial  state  of  W(X).  Then 
sxreate_  requested  — t.create_  requested,  s.run=t.run,  s.write-lockholders  is  the  set  of  T  such 
that  t.intentions(T)  contains  a  deed  whose  first  component  is  a  write  access  to  X,  and  s.read- 
lockholders  is  the  set  of  T  such  that  t.intentions(T)  contains  a  deed  whose  first  component  is  a 
read  access  to  X. 

Lemma  55:  Let  M(X)  be  constructed  using  a  permissible  classification  of  accesses  to  X.  Let 
a  be  a  well-formed  schedule  of  M(X)  that  is  also  a  well-formed  schedule  of  W(X).  Let  s  be  a 
state  of  M(X)  reached  by  applying  a  to  an  initial  state  of  M(X),  and  let  t  be  the  unique  state 
of  W(X)  reached  by  applying  a  to  the  initial  state  of  W(X).  Then  for  every  transaction  T 
perform(write(total(t,T)))  is  a  well-formed  schedule  of  basic  object  X  that  can  leave  X  in  the 
state  s.map(T’),  where  T’  is  the  least  ancestor  of  T  such  that  T’  €  s.write-lockholders. 

Proof:  We  use  induction  on  the  length  of  a.  The  basis  case  is  trivial,  so  let  a  =  a'n,  where 
a’  is  a  well-formed  schedule  of  M(X).  Let  s’  denote  a  state  of  M(X)  after  applying  a'  such  that 
(s’,ir,s)  is  a  step  of  M(X).  Also  let  t’  denote  the  state  of  W(X)  after  a’.  There  are  five  cases, 
for  each  of  which  we  will  relate  s.map  to  s’.map,  and  perform(write(total(t,T)))  to 
perform(write(total(t’,T))). 

(1)  n  is  CREATE(U)  for  an  access  U  to  X. 

The  postconditions  of  ir  as  an  operation  of  M(X)  and  W(X)  show  that  s.map— s’.map,  s.write- 
lockholders=s’.write-lockholders,  and  t. intentions— t’. intentions.  Thus  T’  is  also  the  least 
ancestor  of  T  in  s’.write-lockholders,  and  so  the  induction  hypothesis  says  that 
perform(write(total(t,,T)))  is  a  well-formed  schedule  of  X  that  can  leave  X  in  state  s’.map(T’). 
That  is,  per form( wri te{  total( t , T)))  is  a  well-formed  schedule  of  X  that  can  leave  X  in  state 

s. map(T’). 

(2)  »  is  REQUEST  _  COMMIT(U,U)  for  U  a  read  access  to  X. 

Examining  the  postconditions  for  w  as  an  operation  of  M(X)  and  W(X)  we  see  that 
s  map(W)=s’.map(W)  for  all  W,  and  s.write-lockholders  =  s’.write-lockholders,  and  also 

t. intentions(W)=t’.intentions(W)  unless  W=U.  Thus  T’  is  the  least  ancestor  of  T  in  s’.write- 
lockholders,  and  s.map(T’)=s.map{T’).  Also,  if  T  y*  U,  total(t,T)=total(t’,T).  On  the  other 
hand,  if  U=T,  total(t,T)==total(t’,T)(U,u)l  so  write(total(t,T))— write(total(t’,T)).  In  either 
case,  perform(write(totai(t,T)))=perforro(write(total(t’,T)))),  which  is,  by  the  induction 
hypothesis,  a  well-formed  schedule  of  X  that  can  leave  X  in  state  s’.map(T’)— s.map(T’),  as 
required. 

(3)  :r  is  REQUEST  _COMMIT(U,u)  for  U  a  write  access  to  X. 

Examining  the  postconditions  for  it  as  an  operation  of  M(X)  and  W(X)  we  see  that 
s.map(W)== s’.map(W)  unless  W=U,  and  s.write-lockholders  =  s’.write-lockholders  U  {W}, 
and  also  t.intentions(W)— t’.intentions(W)  unless  W=U.  Thus  if  U  ^  T,  T’  is  the  least 
ancestor  of  T  in  s’.write-lockholders,  and  s.map(T')==s’.map{T’).  Also,  if  T  ^  U, 
total(t,T)=total(t’,T),  and  so  the  induction  hypothesis  shows  that 
perform(write(total(t,T)))— perform(write(total(t’lT))))  is  a  well-formed  schedule  of  basic  object 
X  that  can  leave  X  in  state  s'.map{T’)=s.map(T’).  On  the  other  hand,  if  U=T, 
total(t,T)=*=total(t’,U)(U,u),  so  perform(write(total(t,T)))  = 

perform(write(total(t’,U)))perform(U,u).  Since  *  is  enabled  as  an  operation  of  M(X)  in  state  s’, 
perform(U,u)  can  take  place  starting  from  state  s’.map(U’)  where  U’=least(s’.write- 
lockholders),  and  the  postconditions  for  n  ensure  that  s.map(U)  is  a  state  that  can  result  from 
this  application.  Since  all  members  of  s’.write-lockholders  must  be  ancestors  of  U,  U’  is  the 
least  ancestor  of  U  in  s’.write-lockholders,  and  so  the  induction  hypothesis  implies  that 
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perform(write(total(t,,U)))  is  a  well-formed  schedule  of  basic  object  X  that  can  leave  X  in  state 
s’.map(U’)..  Combining  these  facts,  we  see  that  when  U=T,  perform(write(total(t,T)))  is  a  well- 
formed  schedule  of  X  that  can  leave  X  in  state  s.map(U)— s.map(T),  as  required. 

(4)  i r  is  INFORM _ COMMIT _ AT(X)OF(U) 

Now  t.intentions(W)=t’.intentions(W)  unless  W=U  or  W=parent(U).  Similarly 
s.map(W)=s’.map(W)  unless  W=U  or  W=parent(U).  The  discussion  is  divided  into  subcases, 
depending  on  the  relation  of  T  and  U  in  the  transaction  tree. 

(i)  U  is  an  ancestor  of  T. 

If  U  is  the  least  ancestor  of  T  in  s’.WTite-lockholders  then  by  the  definition  of  M(X),  T’  must 
be  parent(U)  and  s.map(T’)  =  s’.map(U),  while  if  U  is  not  the  least  ancestor  of  T  in  s’.write- 
lockholders  then  T’  must  be  the  least  ancestor  of  T  in  s’.write-lockholders  and  s.map(T’)  = 
s’.map(T’).  In  either  case,  s.map(T’)  is  s’.map(T”),  where  T”  is  the  least  ancestor  of  T  in 
s’.write-lockholders.  Also  total(t,T)=total(t’,T).  The  desired  result  follows  immediately  from 
the  inductive  hypothesis. 

(ii)  U  is  not  an  ancestor  of  T,  but  parent(U)  is  an  ancestor  of  T. 

Here  we  give  separate  arguments,  depending  on  whether  U  is  in  s’.write-lockholders  or  not.  If 
U  €  s’.write-lockholders  then  Lemma  53  implies  that  no  ancestor  of  T  that  is  a  strict 
descendant  of  parent(U)  can  be  in  s’.write-lockholders  or  in  s’.read-lockholders.  The  definition 
of  M(X)  therefore  shows  that  T’  =  parent(U)  and  that  s.map(T’)  —  s’.map(U).  Also  we  note 
that  some  deed  in  t’. intentional))  must  be  a  deed  of  a  write  access,  and  that  t’.intentions(W) 
must  be  empty  for  all  W  that  are  ancestors  of  T  and  strict  descendants  of  parent(U). 
Therefore  total(t,T)=total(t,parent(U))=total(t’,U).  By  the  induction  hypothesis 
perform(write(tota!(t’,U)))  is  a  well-formed  schedule  of  X  that  can  leave  X  in  state  s’.map(U), 
that  is  perform(write(total(t,T)))  is  a  well-formed  schedule  of  X  that  can  leave  X  in  state 
s.map(T). 

On  the  other  hand,  if  U  £  s’.write-lockholders  then  s.write-lockholders  =  s’.write-lockholders 
and  s.map  =  s’.map.  Thus  T’  is  the  least  ancestor  of  T  in  s’.write-lockholders,  and 
s.map(T’)=s’.map(T’).  Also  no  deed  in  t’.intentions(U)  can  be  a  deed  of  a  write  access.  Since 
total(t.T)  is  formed  from  total(t’,T)  by  the  insertion  of  t’.intentions(U)  after  the  prefix 
total(t’,parent(U)),  write(total(t,T))=write(total(t’,T)).  Thus  perform(write(total(t,T)))  = 
perform(write(total(t’,T)))  is,  by  the  induction  hypothesis,  a  well-formed  schedule  of  basic 
object  X  that  can  leave  X  in  state  s’.map(T’)— s.map(T’)  as  required. 

(iii)  parent(U)  is  not  an  ancestor  of  T. 

Then  T’  is  the  least  ancestor  of  T  in  s’.write-lockholders  and  s.map(T’)  =  s’.map(T’).  Also 
total(t,T)=total(t’,T).  The  desired  result  follows  immediately  from  the  inductive  hypothesis. 

(5)  it  is  INFORM _ ABORT _AT(X)OF(U). 

We  distinguish  two  subcases,  according  to  the  relationship  between  U  and  T.  If  U  is  an 
ancestor  of  T,  then  total(t,T)=total(t,parent(U))=total(t’,parent(U)),  as  t.intentions(U’)  is 
empty  for  all  U’  descended  from  U,  but  is  equal  to  t’.intentions(U’)  otherwise.  By  the  induction 
hypothesis,  perform(write(total(t,T)))  =  perform(write(total(t\parent(U))))  is  a  well-formed 
schedule  of  X  that  can  leave  X  in  state  s’.map(T”),  where  T”  is  the  least  ancestor  of  parental)) 
in  s’.write-lockholders.  However,  since  s.writc-lockh  Iders  =s’.write-lockholders 
descendants(U),  T”  is  also  the  least  ancestor  of  T  in  s.write-lockholders,  thus  T”=T’.  Since 
s.map(T”)— s’.map(T”),  as  T”  is  not  a  descendant  of  l1,  this  completes  the  proof  of  the  lemma 
in  this  subcase. 
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If  U  is  not  an  ancestor  of  T,  then  total(t,T)=»total(t’,T),  so  by  the  induction  hypothesis 
perform(write(total(t,T)))  is  a  well-formed  schedule  of  X  that  can  leave  X  in  state 
s’.map(T')=s.map(T’),  since  T’  is  also  the  least  ancestor  of  T  in  s’.write-lockholders.  □ 

Lemma  57 1  Let  M(X)  be  constructed  using  a  permissible  classification  of  the  accesses  to  X 
and  let  a  be  a  well-formed  schedule  of  M(X).  Then  a  is  a  well-formed  schedule  of  W(X). 

Proof:  Since  the  definition  of  well-formedness  is  the  same  for  all  generic  objects,  we  need 
only  show  that  a  is  a  schedule  of  VV(X).  We  use  induction  on  the  length  of  a.  The  basis  case  is 
trivial,  so  let  a  —  a' it,  where  o’  is  a  well-formed  schedule  of  M(X).  If  n  is  an  input  to  W(X), 
the  Input  Condition  implies  that  a  is  a  schedule  of  W(X).  Thus  we  have  only  two  other  cases 
to  consider. 

(1)  n  is  REQUEST  _COMMIT(U,u)  for  U  a  read  access  to  X. 

Let  s’  denote  a  state  of  M(X)  after  applying  a’  such  that  it  is  enabled  as  an  operation  of  M(X) 
after  s’.  Let  t’  denote  the  state  of  W(X)  after  o’.  We  wish  to  show  that  it  is  enabled  as  an 
operation  of  W(X)  in  state  t’.  That  is,  we  need  to  show  that  U  €  t’.create_requested  -  t’.run, 
that  whenever  U’  f?  ancestors(U)  and  (V,v)  is  a  deed  in  t’.intentions(U’)  then  ((U,u),(V,v))  j? 
CONFLICT,  and  that  perform(total(t’,U)(U,u))  is  a  schedule  of  basic  object  X.  Since  jt  is 
enabled  as  an  operation  of  M(X)  in  state  s’,  we  have  that  U  6  s’.create_requested  -  s’.run, 
that  whenever  U’  €  s’.write-lockholders  then  U’  €  ancestors(U),  and  that  perform(U,u)  can  be 
performed  by  X  from  state  s’.map(least(s’.write-lockholders)). 

Lemma  55  shows  that  t’.create_ requested  =  s’.create_ requested,  and  t’.run  =  s’.run. 
Therefore  we  deduce  that  U  €  t’.create_  requested  -  t’.run. 

Lemma  55  also  shows  that  when  V  is  a  write  access  such  that  (V,v)  is  a  deed  in 
t’.intentions(U’),  then  U’  €  s’.write-lockholders,  and  hence  U’  must  be  an  ancestor  of  U.  Also, 
since  U  is  a  read  access,  the  construction  of  the  CONFLICT  relation  shows  that  ((U,u)(V,v))  6 
CONFLICT  implies  that  either  U=V,  or  else  V  is  a  write  access.  Therefore,  if  (V,v)  is  a  deed 
in  t’.intentions(U’)  (so  U’  is  an  ancestor  of  V)  and  ((U,u),(V,v))  6  CONFLICT,  the  facts  just 
proved  show  that  U’  must  be  an  ancestor  of  U.  Equivalently,  if  U’  is  not  an  ancestor  of  U,  and 
(V,v)  is  a  deed  in  t’.intentions(U’)  then  ((U,u),(V,v))  £  CONFLICT. 

Finally,  let  U’=  leases’  .write- lockholders) .  We  note  that  U’  must  be  an  ancestor  of  U  and  is 
thus  the  least  ancestor  of  U  in  s’.write-lockholders.  Therefore  Lemma  56  implies  that 
perform(write(total(t’,U)))  is  a  schedule  of  X  that  can  leave  X  in  state  s’.map(U’).  Then  we  can 
deduce  that  perform(write(total(t’,U)))perform(U,u)  is  a  schedule  of  X.  Since 
perform(write(tota](t’.U)))  is  equieffective  to  perform(total(t’,U)), 

perform(total(t’,U))perform(U,u)  =  perform(total(t’,U)(U,u))  is  a  schedule  of  basic  object  X, 
since  it  is  well-formed.  This  completes  the  proof  that  a  is  a  schedule  of  W(X). 

(2)  it  is  REQUEST_COMMIT(U,u)  for  U  a  write  access  to  X. 

Let  s’  denote  a  state  of  M(X)  after  applying  o’  such  that  it  is  enabled  as  an  operation  of  M(X) 
after  s’.  Let  t’  denote  the  state  of  W(X)  after  o’.  We  wish  to  show  that  it  is  enabled  as  an 
operation  of  W(X)  in  state  t’.  The  proof  that  U  €  t’.create_ requested  -  t’.run,  and  that 
perform(total(t’,U)(U,u))  is  a  schedule  of  basic  object  X,  is  identical  to  that  in  case  (1)  above. 
We  also  must  show  that  whenever  U’  £  ancestors(U)  and  (V,v)  is  a  deed  in  t’.intentions(U’) 
then  ((U,u),(V,v))  £  CONFLICT.  We  will  prove  the  equivalent  statement  that  if 
t’.intentions(U’)  is  not  the  empty  sequence,  then  U’  €  ancestors(U).  By  Lemma  55,  if  (V,v)  € 
t’.intentk>ns(U’)  and  V  is  a  write  access  then  U  6  s’.write-lockholders,  while  if  (V,v)  6 
t’.intentions(U’)  and  V  is  a  read  access  then  U  6  s’.read-lockholders.  However,  since  it  is 
enabled  as  an  operation  of  M(X)  in  state  s’,  we  have  that  whenever  U’  6  s’.read-lockholders  U 
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s’.write-lockholders  (hen  U’  €  ancestors(U),  completing  the  demonstration  that  a  is  a  schedule 
ofWpC).  □ 

Corollary  68:  Let  M(X)  be  constructed  using  a  permissible  classification  of  accesses  at 
X.  Then  M(X)  is  local-dynamic  atomic. 

An  immediate  consequence  of  Corollary  58,  Lemma  42,  and  Corollary  34  is  that  if  S  is  a  R/W  Locking 
system,  that  is  a  generic  system  in  which  each  generic  object  is  a  R/W  Locking  object  for  any  permissible 
classification  of  accesses  to  that  object,  then  S  is  serially  correct  for  all  non-orphan  transactions.  This  was 
the  main  result  of  [FLMWj.  Furthermore,  we  note  that  it  is  always  permissible  to  classify  all  accesses  as 
write  accesses.  If  that  is  done,  Moss’  algorithm  degenerates  into  Exclusive  Locking.  Thus  our  results  also 
imply  the  correctness  of  Exclusive  Locking  systems,  which  was  the  main  theorem  of  [LM]  (albeit  with 
slight  differences  in  the  definitions  of  the  system  components). 

10.  Conclusions  and  Further  Work 

We  have  used  I/O  automata  to  provide  clear  formal  descriptions  of  all  the  components  of  a  nested 
transaction  system.  We  have  demonstrated  that  any  schedule  of  a  Conflict-Based  Locking  system  is 
serially  correct  for  every  non-orphan  transaction.  We  have  also  shown  that  our  new  conflicfehased 
algorithm  can  be  combined  with  Moss’  algorithm  using  read-  and  write-locks.  Indeed,  we  have  shown  that 
a  nested  transaction  system  is  serially  correct  so  long  as  each  data  object  has  a  simple  local  property 
called  dynamic  atomicity.  We  have  shown  bow  to  take  any  schedule  of  such  a  system,  extract  a 
subsequence  (including  all  the  operations  of  a  given  non-orphan  transaction),  and  rearrange  the  events  in 
the  subsequence  to  give  a  serial  schedule. 

This  work  by  no  means  exhausts  the  topic  of  concurrency  control  and  recovery  in  nested  transaction 
systems.  Recent  work  on  timestamp-based  concurrency  control  [As]  uses  arguments  very  similar  to  those 
in  this  paper.  We  hope  in  the  near  future  to  combine  these  results  in  a  uniform  framework.  We  also  hope 
to  extend  the  results  of  this  paper  in  several  ways.  One  natural  extension  is  to  locking  protocols  for 
abstract  data  types  that  are  built  by  combining  atomic  entities  of  primitive  type,  for  example  a  queue 
built  from  atomic  elements.  Such  protocols  have  been  studied  in  transaction  systems  without  nesting 
[We].  We  expect  that  it  should  be  possible  to  prove  that  the  combined  type  is  dynamic  atomic  if  the 
individual  entries  are. 

Other  aspects  of  real  systems  that  we  have  not  addressed  in  this  paper,  but  expect  to  study  in  the 
future,  are  liveness  properties  and  resilience  to  system  crashes.  We  have  proved  that  aay  response  to  a 
Conflict-Based  Locking  system  is  correct,  but  for  a  practical  system  we  also  need  to  know  that  a  response 
will  be  produced  (and,  we  hope,  rapidly  produced.)  Lynch  and  Tuttle  [LT]  discuss  how  to  express  liveness 
results  in  terms  of  I/O  automata,  but  phenomena  such  as  deadlock  in  transaction  systems  make  it 
difficult  to  guarantee  strong  liveness  properties.  At  best,  any  guarantees  that  progress  can  be  made  will 


be  probabilistic.  System  crashes,  that  cause  information  (such  as  lock  tables)  to  be  lost,  are  also  a  reality 
of  practical  systems.  We  plan  to  extend  the  model  presented  in  this  paper  to  describe  crashes,  and  to 
analyze  algorithms  that  ensure  resilience  to  crashes. 
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